Loïc BoninLB
← Veille

ia

Guide de l'orchestration multi-agents

15 juillet 2026·10 min de lecture

Au-delà du modèle unique : Guide de l'interopérabilité et de l'orchestration multi-agents en 2026

Faire résoudre une tâche simple à un unique agent IA est aujourd'hui assez commun. Le véritable défi commence quand vous devez automatiser un flux de travail complexe en entreprise sans construire un prompt gigantesque, impossible à déboguer et sujet aux hallucinations. En 2026, l'industrie a abandonné l'agent universel au profit d'architectures modulaires basées sur la division du travail.

Pour y parvenir, il faut comprendre deux concepts distincts : l'orchestration multi-agents (comment coordonner des agents spécialisés au sein d'un même système) et l'interopérabilité (comment faire communiquer des agents développés sur des piles technologiques différentes).

Pourquoi diviser pour régner ?

Lorsqu'un unique agent LLM tente de lire une base de données, d'en analyser les métriques, d'écrire un rapport technique et de générer un e-mail de synthèse, il s'effondre sous le poids du contexte. La précision de son attention diminue et le taux d'erreur grimpe en flèche.

L'orchestration multi-agents applique les principes classiques du génie logiciel à l'intelligence artificielle :

  • La spécialisation : Un agent chercheur récupère les données brutes, un autre agent rédacteur rédige le texte, et un autre agent critique valide la conformité réglementaire.
  • La réduction du contexte : Chaque agent ne reçoit que les informations nécessaires à sa tâche immédiate, réduisant les risques d'oubli ou d'invention de faits.
  • Le contrôle de l'état : Vous pouvez insérer des étapes de validation humaine ou des tests automatisés déterministes entre les interventions des différents agents.

Le harnais d'agent (agent harness) et les sous-agents (Subagents)

Pour fonctionner correctement, un modèle de langage a besoin d'être encapsulé. C'est le rôle du harnais d'agent (Agent Harness), c'est-à-dire l'ensemble des outils et de l'environnement qui entourent le modèle pour lui donner une existence concrète. Ce harnais gère la mémoire persistante, l'accès aux API sécurisées, les journaux d'exécution et les politiques de sécurité (comme la détection d'injections de prompts).

À l'intérieur de ce harnais, le concept de sous-agent (Subagent) s'est imposé comme un outil interne très efficace.

Plutôt que de donner à un agent principal l'accès direct à votre terminal ou à votre base de données, l'agent principal utilise son harnais pour instancier un sous-agent éphémère. Ce sous-agent reçoit une mission ultra-spécifique (par exemple : "trouve la ligne 42 du fichier de configuration et renvoie son contenu"). Une fois la tâche accomplie, le sous-agent est détruit et ne renvoie que le résultat brut. Cela évite que l'agent principal ne soit pollué par l'historique de navigation dans le système de fichiers.

Claude Code : la communication inter-agents en natif

On vas commencer par ce qui se fait de plus simple: Claude Code intègre nativement deux modes de communication entre agents, documentés officiellement sous les noms de sous-agents (subagents) et d'équipes d'agents (agent teams).

Le modèle hub-and-spoke : les sous-agents

Par défaut, Claude Code utilise un modèle où la session principale instancie des sous-agents via l'outil Agent. Chaque sous-agent s'exécute dans sa propre fenêtre de contexte, avec un prompt système personnalisé, un accès aux outils spécifique et des permissions indépendantes ; il travaille de façon autonome puis renvoie son résultat à l'appelant. La documentation officielle recommande ce mode précisément pour éviter qu'une tâche annexe (résultats de recherche, contenu de fichiers volumineux) ne vienne saturer la conversation principale.

Les sous-agents sont des fichiers Markdown stockés dans .claude/agents/ pour un usage limité au projet, ou dans ~/.claude/agents/ pour un usage partagé entre tous les projets :

yaml
---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Grep, Glob
model: sonnet
---
You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.

Seuls les champs name et description sont obligatoires ; le champ model accepte un alias (sonnet, opus, haiku, fable), un identifiant de modèle complet, ou inherit pour reprendre le modèle de la conversation principale (comportement par défaut). Claude Code inclut aussi trois sous-agents intégrés utilisés automatiquement : Explore (lecture seule, optimisé pour la recherche dans le code), Plan (utilisé en mode plan pour la recherche de contexte) et general-purpose (accès à tous les outils, pour les tâches complexes en plusieurs étapes).

Le contrôle de la récursion se fait par la présence de l'outil Agent dans la liste tools du sous-agent : si Agent est absent, ce sous-agent ne peut spawner aucun enfant. Et en employant une syntaxe d'allowlist, Agent(worker, researcher)on peut autoriser un agent à ne spawner que certains types de sous-agents précis. Ce mécanisme fait partie des sécurités mises en place par les concepteurs de Claude Code pour limiter les dérives potentielles, et constitue un garde-fou contre une consommation incontrôlée de tokens par délégation en cascade.

Les Agent Teams (expérimental) : le maillage peer-to-peer

Pour les scénarios où plusieurs agents doivent collaborer horizontalement plutôt que répondre à un parent, Claude Code propose les Agent Teams, une fonctionnalité explicitement qualifiée d'expérimentale et désactivée par défaut. Elle s'active en ajoutant CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS avec la valeur 1, soit dans l'environnement shell, soit dans settings.json :

json
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}

L'architecture repose sur quatre composants : le team lead (la session principale, qui spawne les coéquipiers et coordonne le travail), les teammates (des instances Claude Code séparées, chacune sur une tâche assignée), la task list (liste de travaux partagée que les coéquipiers réclament et complètent) et la mailbox (un fichier JSON par agent, à l'adresse ~/.claude/teams/{team-name}/inboxes/{agent-name}.json, qui sert de système de messagerie inter-agents). Le pouvoir des coéquipiers sur les permissions est encadré : un teammate ne peut ni approuver une invite de permission à la place de l'utilisateur, ni relayer une autorisation obtenue par un autre agent pour contourner un contrôle refusé. un garde-fou contre l'escalade de privilèges entre agents.

C'est en expérimental pour une bonne raison, il y a encore des limites : aucune reprise de session pour les coéquipiers en mode "in-process" après un /resume, aucune équipe imbriquée, un seul lead fixe pour la durée de la session, et une seule équipe active par session. Pour de la coordination transverse entre le front et le back, pour de la revue de code croisée, ou du développement de modules indépendants, ou encore tester du débug par hypothèses concurrentes. Pour des modifications sur un même fichier, où un sous-agent classique reste plus efficace.

Les orchestrateurs multi-agents :

Après ce petit tour d'horizon de CLaude Code, passons aux projets plus matures, dédié aux fonctionnement multi-agents.

CrewAI : l'orchestration multi-agents par les rôles

CrewAI part d'une analogie basé celle d'une équipe humaine. Le framework, open source organise ses agents autour de rôles, d'objectifs et d'un historique narratif propre à chacun.

Les trois briques de base : agents, tâches, équipe

L'architecture de CrewAI s'articule autour de trois éléments qui s'assemblent toujours dans le même ordre. Chaque agent est défini avec un rôle métier (par exemple "analyste financier"), un objectif explicite, et une "backstory" narrative qui cadre son comportement et son ton. Chaque tâche est ensuite assignée à un agent précis, avec une description de ce qui est attendu en sortie, et éventuellement des dépendances vers d'autres tâches. L'ensemble de ces agents et tâches est enfin regroupé dans un crew, l'objet qui orchestre concrètement l'exécution.

Deux modes d'exécution : séquentiel et hiérarchique

CrewAI propose nativement deux modes de coordination entre agents, appelés "Processes". Le mode séquentiel exécute les tâches les unes après les autres, dans un ordre fixe défini à l'avance, ce qui convient à des flux de travail linéaires et prévisibles. Le mode hiérarchique introduit un agent manager qui répartit dynamiquement les tâches vers les agents les plus adaptés, avec une délégation gérée automatiquement par le framework.

Les Flows : la réponse de CrewAI au besoin de contrôle fin

Pour les cas où le modèle purement séquentiel ou hiérarchique ne suffit pas, CrewAI a introduit les Flows, une couche complémentaire pour l'"architecture de production". Les Flows permettent de définir un état partagé entre les étapes, de contrôler précisément les chemins d'exécution avec des boucles et des branchements conditionnels, et de persister l'exécution pour reprendre un workflow interrompu. La documentation officielle recommande d'ailleurs une combinaison des deux : utiliser les Flows pour le contrôle global de l'état, et réserver les Crews aux sous-tâches suffisamment complexes pour justifier une collaboration multi-agents.

Un choix pragmatique plutôt que technique

Ce qui distingue vraiment CrewAI dans le paysage 2026 n'est pas tant une supériorité technique sur les autres orchestrateurs, mais un choix d'ergonomie : la définition d'agents en YAML et l'abstraction "équipe" réduisent significativement le temps nécessaire pour passer d'un prototype à un premier déploiement fonctionnel. CrewAI est un bon orchestrateur multi-agents si vous privilégiez la rapidité de mise en œuvre et l'expérience développeur, tandis que des frameworks plus bas niveau restent préférables dès que l'auditabilité fine de chaque décision devient une exigence non négociable. CrewAI prend également en charge une large variété de fournisseurs de modèles, ce qui en fait un choix agnostique du fournisseur plutôt qu'un outil lié à un seul écosystème de modèles.

Exemple minimal : un crew à un agent

Pour illustrer la mécanique, voici la structure minimale recommandée par la documentation officielle en 2026 : un agent, une tâche, et un Flow qui orchestre l'exécution.

L'agent est défini dans un fichier agents/researcher.jsonc, séparé du code Python :

jsonc
{
"role": "{topic} Senior Data Researcher",
"goal": "Découvrir les développements récents sur {topic}",
"backstory": "Un chercheur expérimenté qui trouve l'information pertinente et la présente clairement.",
"llm": "anthropic/claude-sonnet-4-6",
"tools": ["SerperDevTool"],
"settings": {
"verbose": true,
},
}

La tâche et le crew sont assemblées dans crew.jsonc :

jsonc
{
"name": "Research Crew",
"agents": ["researcher"],
"tasks": [
{
"name": "research_task",
"description": "Effectue une recherche approfondie sur {topic}.",
"expected_output": "Un rapport markdown structuré avec les tendances clés.",
"agent": "researcher",
"output_file": "output/report.md",
},
],
"process": "sequential",
}

Le Flow Python, enfin, définit l'état partagé et déclenche la crew au bon moment :

python
from crewai import Agent, Crew, Process, Task
from crewai.flow.flow import Flow, listen, start
from pydantic import BaseModel
 
 
class ResearchFlowState(BaseModel):
topic: str = ""
report: str = ""
 
 
class LatestAiFlow(Flow[ResearchFlowState]):
 
@start()
def prepare_topic(self):
self.state.topic = "orchestration multi-agents"
 
@listen(prepare_topic)
def run_research(self):
researcher = Agent(
role=f"{self.state.topic} Senior Data Researcher",
goal=f"Découvrir les développements récents sur {self.state.topic}",
backstory="Un chercheur expérimenté qui trouve l'information pertinente.",
)
research_task = Task(
description=f"Effectue une recherche approfondie sur {self.state.topic}.",
expected_output="Un rapport markdown structuré avec les tendances clés.",
agent=researcher,
)
research_crew = Crew(
agents=[researcher],
tasks=[research_task],
process=Process.sequential,
)
 
result = research_crew.kickoff(inputs={"topic": self.state.topic})
self.state.report = result.raw
 
 
if __name__ == "__main__":
LatestAiFlow().kickoff()

Cet exemple illustre le principe central de l'architecture CrewAI actuelle : le Flow possède l'état et l'ordre d'exécution, tandis que le Crew ne gère que l'intelligence collaborative d'une étape précise, appelée depuis ce Flow. C'est cette séparation entre orchestration (Flow) et collaboration (Crew) que la documentation recommande pour toute application destinée à la production.

Microsoft Agent Framework : l'héritier direct d'AutoGen et de Semantic Kernel

Le Microsoft Agent Framework (MAF) n'est pas un projet parti de zéro : il s'agit du successeur officiel et direct d'AutoGen et de Semantic Kernel, construit par les mêmes équipes qui ont créé ces deux frameworks. Cette généalogie explique un choix de conception central : MAF combine les abstractions simples d'AutoGen pour la conversation multi-agent avec les fonctionnalités d'entreprise de Semantic Kernel: une gestion d'état basée sur des sessions, la sécurité de typage, le middleware, la télémétrie, tout en ajoutant une couche pour l'orchestration explicite. Le projet est open source sur GitHub microsoft/agent-framework.

Agents et Workflows : deux briques distinctes, pas une seule abstraction

MAF sépare explicitement deux notions:

  • Un agent qui correspond à un LLM individuel capable de traiter des entrées, d'appeler des outils ou des serveurs MCP, et de générer une réponse.
  • Un workflow qui est un flux basé sur un graphe qui connecte plusieurs agents et fonctions pour des tâches en plusieurs étapes, avec routage sécurisé par typage, points de contrôle, et intégration humaine dans la boucle.

Les patterns d'orchestration natifs

Les patterns de workflows pris en charge nativement sont : séquentiel, concurrent, handoff (transfert de contrôle d'un agent à un autre) et collaboration de groupe, avec streaming, points de reprise et voyage dans le temps (time-travel) pour rejouer une exécution passée. C'est un des rares frameworks à documenter aussi explicitement le pattern handoff comme primitive de premier ordre, un scénario fréquent par exemple pour le support client où un agent généraliste doit transférer la conversation à un agent spécialisé sans perdre le contexte accumulé.

Agents déclaratifs en YAML et Agent Skills

Deux fonctionnalités rapprochent directement MAF de la logique déjà vue avec les sous-agents Claude Code et les définitions JSONC de CrewAI. Les agents déclaratifs permettent de définir un agent entièrement en YAML pour accélérer sa mise en place et faciliter son versionnement dans un dépôt Git. Les Agent Skills permettent eux de construire des bases de connaissances spécifiques à un domaine que l'agent peut ensuite découvrir et utiliser dynamiquement.

Observabilité, DevUI et hébergement Foundry

MAF intègre OpenTelemetry nativement pour le traçage distribué, le monitoring et le débogage, ce qui le connecte directement aux standards d'observabilité évoqués dans cet article. Le framework propose aussi une DevUI, une interface de développement interactive pour tester et déboguer des workflows d'agents localement avant tout déploiement.

Un point de vigilance : le lien avec l'écosystème Azure

Si MAF reste open source et supporte des fournisseurs de modèles tiers comme Anthropic, sa documentation et ses exemples restent structurellement centrés sur l'écosystème Microsoft Foundry et Azure : authentification via Azure CLI ou identités managées, hébergement recommandé sur Foundry... C'est à prendre en compte avant de choisir MAF pour un projet qui doit rester totalement agnostique du cloud.

Installation minimale

bash
pip install agent-framework
python
import asyncio
from agent_framework import Agent
from agent_framework.foundry import FoundryChatClient
from azure.identity import AzureCliCredential
 
 
async def main():
agent = Agent(
client=FoundryChatClient(credential=AzureCliCredential()),
name="HaikuAgent",
instructions="Tu es un assistant enthousiaste qui écrit avec élégance.",
)
print(await agent.run("Écris un haïku sur Microsoft Agent Framework."))
 
 
if __name__ == "__main__":
asyncio.run(main())

Cet exemple minimal illustre la structure de base : un client de modèle (ici connecté à Microsoft Foundry), instancié dans un Agent, appelé de façon asynchrone. Passer de cet agent unique à un workflow multi-agent ne change pas cette base.

Mini-exemple : un workflow séquentiel à deux agents

L'exemple suivant met en scène un agent de réception d'hôtel (FrontDesk) qui propose une recommandation, relue ensuite par un agent concierge (Concierge) qui l'affine. La construction du workflow tient en une seule ligne fluide, via WorkflowBuilder :

python
import asyncio
from agent_framework import WorkflowBuilder, WorkflowEvent
from agent_framework.azure import AzureOpenAIChatClient
from azure.identity import AzureCliCredential
 
 
async def main():
chat_client = AzureOpenAIChatClient(credential=AzureCliCredential())
 
front_desk_agent = chat_client.create_agent(
name="FrontDesk",
instructions=(
"Tu es un agent de réception d'hôtel avec dix ans d'expérience, "
"connu pour la concision de tes recommandations."
),
)
 
concierge_agent = chat_client.create_agent(
name="Concierge",
instructions=(
"Tu es un concierge qui privilégie les expériences locales et "
"authentiques. Relis la suggestion reçue et propose une alternative "
"moins touristique si nécessaire."
),
)
 
workflow = (
WorkflowBuilder()
.set_start_executor(front_desk_agent)
.add_edge(front_desk_agent, concierge_agent)
.build()
)
 
result = ""
async for event in workflow.run_stream("Je voudrais aller à Paris."):
if isinstance(event, WorkflowEvent):
result += str(event.data)
 
print(result)
 
 
if __name__ == "__main__":
asyncio.run(main())

Trois éléments méritent d'être compris ici :

  • Chaque agent créé via chat_client.create_agent devient un executor, l'unité de traitement de base du moteur de workflow, capable de recevoir un message et d'en émettre un nouveau en sortie.
  • add_edge(front_desk_agent, concierge_agent) définit une edge : la sortie complète du premier agent devient l'entrée du second.
  • Le moteur d'exécution sous-jacent suit un modèle Pregel, où le traitement avance par étapes synchronisées appelées "supersteps": une architecture héritée des systèmes de calcul distribué sur graphes, garantissant un ordre d'exécution déterministe même à grande échelle.

3. LangGraph : l'orchestration déterministe par graphes d'états

LangGraph aborde l'orchestration multi-agents avec une philosophie différente de CrewAI et de MAF : plutôt que de penser en "équipe" ou en "workflow", il pense en graphe. Chaque agent est un noeud, chaque transition entre agents est une arête, et l'état de la tâche circule d'un noeud à l'autre comme un objet unique que chacun peut lire et modifier

Le pattern Superviseur : un agent qui dirige les autres

Imaginez un chef de projet qui ne fait rien lui-même, mais qui lit l'état d'avancement d'un dossier et décide, à chaque étape, qui doit s'en occuper ensuite. C'est exactement le rôle du noeud superviseur dans LangGraph : il inspecte l'état partagé (a-t-on déjà les données ? le rapport est-il rédigé ?) et redirige le flux vers le bon agent spécialiste. Ce qui rend ce pattern puissant, c'est sa capacité à faire des allers-retours : si le rédacteur juge les données insuffisantes, le superviseur peut renvoyer le flux vers le chercheur avant de reprendre la rédaction.

LangChain propose une bibliothèque pour ce pattern, langgraph-supervisor, avec une fonction create_supervisor() qui évite d'écrire cette logique de routage à la main. Mais pour l'exemple, voici la logique en code :

python
from typing import TypedDict
from langgraph.graph import StateGraph, START, END
 
 
class State(TypedDict):
task: str
raw_data: str
draft: str
next_node: str
 
 
def supervisor(state: State):
if not state.get("raw_data"):
return {"next_node": "researcher"}
if not state.get("draft"):
return {"next_node": "writer"}
return {"next_node": "end"}
 
 
def researcher(state: State):
return {"raw_data": "Données récupérées sur le serveur MCP à 10:15"}
 
 
def writer(state: State):
return {"draft": f"Rapport final basé sur : {state['raw_data']}"}
 
 
workflow = StateGraph(State)
workflow.add_node("supervisor", supervisor)
workflow.add_node("researcher", researcher)
workflow.add_node("writer", writer)
 
workflow.add_edge(START, "supervisor")
workflow.add_conditional_edges(
"supervisor",
lambda state: state["next_node"],
{"researcher": "researcher", "writer": "writer", "end": END},
)
workflow.add_edge("researcher", "supervisor")
workflow.add_edge("writer", "supervisor")
 
app = workflow.compile()

Le checkpointing : un point de sauvegarde après chaque étape

Un mécanisme important de LangGraph est simple à résumer avec une analogie de jeu vidéo : dès qu'un graphe est compilé avec un checkpointer, LangGraph fait automatiquement une "sauvegarde" de l'état complet après chaque étape du graphe, chiffré ou non, et identifiée par un thread_id. Cette seule mécanique débloque quatre capacités :

  • Tolérance aux pannes : si une étape échoue, on reprend à la dernière sauvegarde réussie, pas depuis le début.
  • Mémoire : reprendre une conversation ou une tâche des heures ou des jours plus tard, en rechargeant simplement le même thread_id.
  • Voyage dans le temps : revenir à une sauvegarde antérieure pour la rejouer ou explorer une branche alternative, via get_state_history().
  • Human-in-the-loop : mettre le workflow en pause pour demander l'avis d'un humain (avant des actions irréversibles ou nécessitant une validation)

LangGraph permet de suspendre le graphe exactement au moment nécessitant une vérification humaine, grâce à la fonction interrupt(), appelée directement à l'intérieur d'un nœud.

python
from langgraph.types import interrupt, Command
 
def approval_node(state):
is_approved = interrupt({
"question": "Approuvez-vous cette action ?",
"details": state["action_details"],
})
return Command(goto="proceed" if is_approved else "cancel")

Le fonctionnement est simple à retenir : dès que interrupt() est appelé, LangGraph sauvegarde l'état courant et met le graphe en pause indéfiniment, en attendant une réponse. Pour reprendre, il suffit de relancer le graphe avec Command(resume=True) ou Command(resume=False). La valeur passée devient alors la valeur de retour de l'appel interrupt().

Les subgraphs : découper un grand graphe entre plusieurs équipes

Pour une organisation où plusieurs équipes travaillent sur des segments différents d'un même workflow, LangGraph permet d'encapsuler un graphe complet à l'intérieur d'un seul nœud d'un graphe parent: un subgraph. Chaque équipe peut ainsi développer et faire évoluer son propre subgraph indépendamment, en faisant attention à garder stable l'interface d'état qui le relie au graphe parent.

L'interopérabilité entre différents agents harness

Que se passe-t-il si votre agent de support client (bâti en Python sur LangGraph) doit collaborer avec l'agent de facturation de votre partenaire commercial (bâti en Go sur un autre framework) ?

Pour éviter de réécrire une API sur mesure à chaque nouveau partenaire, l'industrie s'appuie en 2026 sur deux protocoles ouverts : A2A pour faire parler deux agents entre eux, et MCP (expliqué en détail dans cet article) pour connecter un agent à ses outils et ses données.

Le protocole A2A : le langage commun entre agents

A2A définit la manière dont deux agents distants s'envoient des requêtes, s'authentifient et échangent des données, y compris les cas où un agent ne comprend pas la demande d'un autre. Donné par Google à la Linux Foundation, le protocole est aujourd'hui géré par le projet Agent2Agent, avec le soutien de fondateurs comme AWS, Cisco, Microsoft, Salesforce et SAP. Ce n'est pas un protocole de niche : plus de 150 organisations le soutiennent désormais, la version 1.0 stable est sortie en mars 2026, et A2A est déjà intégré nativement à Azure AI Foundry, Amazon Bedrock AgentCore et Google Cloud.

La découverte dynamique via l'AgentCard

Pour collaborer, les agents doivent pouvoir se découvrir mutuellement. A2A résout ce problème avec un fichier standardisé, l'AgentCard, publié à l'adresse /.well-known/agent-card.json à la racine du domaine qui héberge l'agent. N'importe quel client peut ainsi récupérer cette carte d'identité d'un simple GET HTTP, sans registre centralisé.

L'AgentCard décrit essentiellement trois choses :

  • Les capacités de l'agent (ce qu'il sait faire).
  • Les formats de données qu'il accepte en entrée et produit en sortie.
  • Comment l'appeler concrètement : l'URL réelle de son point d'entrée, le protocole utilisé, et les identifiants ou jetons requis pour s'authentifier.

Un agent qui veut en solliciter un autre lit d'abord cette carte, vérifie que ses compétences correspondent au besoin, puis l'appelle directement à l'adresse indiquée.

Orchestrer plusieurs agents harness : le cas OmniGent

A2A aide à la communication entre deux agents isolés via un protocole ouvert. Mais lorsqu'une organisation veut exécuter simultanément des agents harness comme Claude Code, Codex et Cursor sur le même projet, avec des politiques communes, un sandboxing unifié et une session partagée accessible depuis n'importe quel appareil, les protocoles seuls ne suffisent pas. Il faut une couche de gouvernance au-dessus des harnais.

C'est ce que propose OmniGent, un framework open-source. Il fonctionne comme un "meta-harnais" : il s'installe une couche au-dessus de Claude Code, Codex, Cursor et de tout agent harness, et les traite comme des modules interchangeables.

Son architecture repose sur quatre capacités distinctes :

  • Portabilité entre agents harness : OmniGent expose une API commune à tous les runtimes d'agents. Vous définissez un workflow une fois. Si vous passez de Claude Code à Codex, vous changez un paramètre de configuration, pas votre logique d'orchestration.
  • Politiques unifiées : Vous définissez une fois vos garde-fous (permissions fichiers, budget de tokens, restrictions réseau) et OmniGent les applique à tous les agents, quelle que soit la technologie sous-jacente. Un agent Claude Code et un agent Codex travaillant en parallèle opèrent dans le même périmètre de sécurité.
  • Sandboxing distribué : les agents peuvent s'exécuter dans des sandbox jetables hébergées sur Modal ou Daytona, provisionnées automatiquement à la demande d'une session. L'orchestrateur gère le cycle de vie des sandbox, leur allocation et leur destruction sans intervention manuelle.
  • Session persistante multi-appareils : OmniGent maintient une session stable accessible via une URL fixe, ce qui permet à une équipe de reprendre une session en cours, avec son historique complet, depuis un terminal, un navigateur ou une application sans interruption du flux de travail.

OmniGent embarque aussi deux orchestrateurs prêts à l'emploi : Polly est un orchestrateur de code multi-agents qui ne code jamais elle-même : elle découpe une tâche en sous-tâches, délègue chacune à un sous-agent sur son propre harnais et sa propre branche git, puis impose une revue croisée où l'implémentation d'un fournisseur est systématiquement relue par un agent d'un fournisseur différent. La fusion finale reste toujours décidée par un humain. Et Debby, un partenaire de brainstorming multi-modèle : elle envoie chaque question à la fois à deux agents avec un modèle LLM différent, et utilise une compétence /debate dédiée à la critique croisée sur plusieurs tours.

omnigent-ai/omnigent

Les défis et limites de la collaboration d'agents

L'architecture multi-agents introduit de nouvelles difficultés de débogage et de sécurité :

  • La latence en cascade : Si l'agent A doit interroger l'agent B qui lui-même attend une réponse de l'agent C, le temps de réponse global peut rapidement devenir inacceptable pour une interface utilisateur interactive.
  • Les boucles infinies de communication : Deux agents mal configurés peuvent entrer dans un cycle d'explications et de corrections mutuelles sans jamais s'arrêter. Les orchestrateurs doivent intégrer des compteurs de boucles d'appels pour imposer une limite.
  • Le problème du "Confused Deputy" : Si un agent de confiance A a accès à vos données sensibles et qu'il accepte d'exécuter une tâche pour le compte d'un agent externe B non autorisé, l'agent A peut être manipulé pour exfiltrer des données. Le harnais de sécurité doit donc valider la chaîne de droits sur chaque action. Ce n'est pas un risque théorique : la vulnérabilité GitHub MCP (une issue malveillante postée sur un dépôt public a manipulé un agent disposant d'un accès à des dépôts privés pour qu'il publie leurs informations sensibles via une pull request publique) et la fuite de données via Supabase MCP (un ticket de support piégé a exposé une table de jetons d'intégration Cursor) ont toutes deux exploité ce schéma exact, où un agent doté d'un accès légitime a été manipulé par une source externe pour agir hors de son intention initiale. La cause racine porte un nom précis en sécurité : l'autorité ambiante, où le droit est attaché à l'identité de l'agent plutôt qu'à chaque requête individuelle, ce qui rend la vérification de l'intention presque impossible après coup.

Conclusion

L'avenir des architectures IA n'est pas aux modèles uniques toujours plus grands, mais à l'assemblage intelligent de modèles spécialisés. À l'intérieur d'une même application, des orchestrateurs comme LangGraph, CrewAI ou le Microsoft Agent Framework structurent la collaboration entre agents grâce à des graphes d'états, des rôles ou des workflows. Entre deux applications ou deux organisations différentes, le protocole A2A et l'architecture MCP permettent à des agents hétérogènes de se découvrir et de communiquer sans réécrire d'API sur mesure. Et des meta-harnais comme OmniGent introduisent une couche de gouvernance transversale pour les agents harness: politiques de sécurité unifiées, sandboxing distribué et sessions partagées, indépendamment de l'outil ou du modèle utilisé en dessous. Tout ces outils contribuent à la conception de systèmes d'agents fiables, supervisés et capables de collaborer au-delà des frontières d'une seule application, d'une seule entreprise ou d'un seul harnais.

Sources et liens utiles :

IAdéveloppement agentiqueAgent