Aller au contenu
Simon Place
FR EN
Réserver un appel Meet

Module 5 sur 10, leçon 2 sur 5

Aller plus loin

Les systèmes multi-agents

Deux positions publiées

En juin 2025, deux équipes d’ingénieurs ont publié des conseils opposés à quelques jours d’écart. Don’t Build Multi-Agents, de Cognition, soutient que des agents en parallèle prennent des décisions contradictoires, car chacun ne voit qu’une partie du contexte. Anthropic décrit de son côté un système de recherche où un orchestrateur et des exécutants parallèles font mieux sur des recherches larges, au prix d’environ 15 fois les tokens d’un chat.

Le désaccord est plus apparent que réel. La recherche se découpe en questions indépendantes, et lire plus de sources en parallèle aide. L’écriture de code ne se découpe pas ainsi : chaque décision contraint la suivante. Demandez-vous donc si les sous-tâches sont indépendantes. Si un exécutant a besoin des choix d’un autre pour travailler, gardez le travail dans un seul agent.

Les schémas

  • Superviseur : un agent délègue et assemble. C’est facile à suivre, et il devient un goulot d’étranglement.
  • Passage de relais : le contrôle passe d’un agent au suivant, comme dans un service client. Un seul parle à la fois, et le contexte peut se perdre à chaque transfert.
  • Tableau partagé : les agents lisent et écrivent un état commun. C’est souple, et il faut des règles sur qui peut écrire quoi.

Partagez des décisions, pas des transcriptions

Transmettre toute une conversation gaspille des tokens et noie l’essentiel. Transmettre une phrase perd les raisons. Un petit état structuré fonctionne mieux :

{
  "goal": "Refund order 4512",
  "decisions": ["Damaged item: policy P-7 applies"],
  "open_questions": ["Was the item already replaced?"],
  "artifacts": ["orders/4512.json"]
}

La consigne vague est la panne la plus courante. « Regarde le remboursement » pousse un exécutant à refaire les recherches du superviseur. Une bonne consigne donne l’objectif, ce qu’on sait déjà, le format attendu et le moment où s’arrêter.

Répartir et rassembler

La répartition demande une limite de concurrence, car les quotas d’API sont partagés. Elle demande aussi une décision sur les échecs partiels : si un exécutant sur cinq échoue, le résultat reste-t-il utilisable ? Le rassemblement concentre les risques. Les exécutants peuvent se contredire, se répéter ou inventer des faits : cette étape a besoin de ses propres instructions et de ses propres tests.

Les erreurs se multiplient

Cinq étapes qui réussissent chacune à 95 % réussissent ensemble dans environ 77 % des cas (0,955). Chaque agent ajouté est un facteur de plus dans ce produit, sauf si une étape suivante attrape réellement les erreurs. Un agent relecteur n’aide que si vous avez mesuré qu’il les trouve.

Mentions légales et confidentialité