L'architecture par défaut des systèmes multi-agents repose sur un chef. Un orchestrateur décompose la tâche, répartit le travail entre les agents, collecte les résultats et décide de ce qui est vrai. C'est facile à comprendre, mais cela hérite aussi des problèmes classiques de tout coordinateur central : c'est un goulot d'étranglement, un point unique de défaillance et, plus subtilement, un plafond — le système ne peut jamais être plus intelligent que le composant chargé de la répartition.
Dans le cadre du cours pratique TUM × SAP, notre équipe de six personnes a passé un semestre à parier sur l'approche inverse. Mycellium est un système multi-agents sans orchestrateur : les agents s'auto-organisent grâce à un état partagé et des règles de décision locales, sans que personne n'ait le dernier mot. J'étais product owner et responsable de l'architecture, j'ai donc vu à la fois le volet conception et le volet « expliquer cela aux parties prenantes de l'industrie ».
Trois mécanismes plutôt qu'un chef
Supprimer l'orchestrateur ne supprime pas ses responsabilités. La répartition des tâches, le partage de l'information et la détermination de ce qui est vrai doivent toujours avoir lieu ; ils doivent simplement se produire sans contrôle central. Mycellium les répartit en trois mécanismes.
Une enchère plutôt qu'un répartiteur. Le travail est décomposé en contrats et en threads, sur lesquels les agents enchérissent. Les offres sont pondérées par la compétence et par la confiance, si bien qu'un agent qui a historiquement bien livré un type de tâche remporte plus souvent des tâches similaires. Personne n'assigne quoi que ce soit ; les agents se sélectionnent eux-mêmes, et cette pondération évite que cette auto-sélection ne tourne à la foire d'empoigne.
Un blackboard plutôt qu'un routeur de messages. L'ensemble de l'état partagé réside sur un blackboard à ajout seul. L'ensemble d'outils fourni aux agents est délibérément restreint : publier une observation, citer celle d'un autre, voter, mentionner un autre agent. Le caractère « ajout seul » compte plus qu'il n'y paraît : rien n'est jamais modifié ou supprimé silencieusement, si bien que l'historique complet de la façon dont l'essaim est parvenu à son résultat reste toujours consultable.
Des citations plutôt qu'un juge. C'est la partie que j'ai trouvée la plus intéressante. Lorsque des agents publient des observations, d'autres agents travaillant sur des threads adjacents s'appuient dessus ou non. Une affirmation qui reçoit des citations indépendantes gagne en crédibilité ; une affirmation sur laquelle personne ne s'appuie s'efface silencieusement. Le consensus n'a pas besoin d'un juge, il a besoin d'un seuil. Il n'existe aucun agent arbitre final décidant de ce qui est vrai, et le système converge malgré tout.
Le simulateur n'était pas optionnel
Il est difficile de faire confiance à un système émergent, précisément parce que personne n'a décidé de son comportement. L'élément le plus précieux que nous ayons construit pour favoriser son adoption ne se trouvait pas du tout dans le protocole : une interface visuelle permettant de configurer un réseau d'agents, de le lancer, puis de rejouer l'essaim étape par étape — chaque enchère, chaque publication, chaque citation et chaque vote, dans l'ordre.
Lorsque nous avons présenté cela aux parties prenantes de SAP, le replay a été bien plus convaincant que les diapositives d'architecture. La « coordination émergente » ressemble à du baratin jusqu'à ce qu'on puisse parcourir une exécution et observer une affirmation erronée être publiée, ne recevoir aucune citation, puis disparaître du résultat. Le même outil a aussi accéléré nos propres revues : quand une exécution partait de travers, nous pouvions retrouver l'étape exacte où cela s'était produit.
Là où je resterais prudent
Je ne pense pas que l'absence d'orchestrateur soit le bon choix par défaut pour tous les systèmes. Cette approche justifie sa complexité lorsque les tâches sont suffisamment décomposables pour qu'une enchère ait du sens, et lorsque l'absence de point unique de défaillance est une priorité. Pour un pipeline étroit avec trois étapes fixes, un orchestrateur est plus simple, et la simplicité l'emporte.
Les leçons générales se sont transposées malgré tout, avec ou sans orchestrateur : donner aux agents des contrats explicites et des surfaces d'outils restreintes, rendre l'état partagé « ajout seul » pour que le comportement reste auditable, et investir tôt dans l'outillage de replay. Ces trois points ont directement influencé la façon dont je pense les systèmes agentiques sur lesquels je travaille en environnement d'entreprise.
Le projet propose une démo en direct si vous souhaitez observer un essaim en action par vous-même. Si vous construisez des systèmes multi-agents et avez des opinions bien arrêtées sur la coordination, j'aimerais sincèrement les entendre.