1. Introduction#
Une architecture multi-agents (Multi-Agent System) repose sur plusieurs agents IA qui collaborent pour atteindre un objectif commun.
Chaque agent peut posséder ses propres :
- instructions et responsabilités ;
- outils et permissions ;
- modèle de langage ;
- contexte et état d’exécution.
L’objectif est de répartir les responsabilités, spécialiser les tâches et coordonner leur exécution.
Un système multi-agents n’est toutefois pas nécessairement plus performant qu’un agent unique. Il introduit des coûts et une complexité supplémentaires.
2. Agent unique et Multi-agents#
| Architecture | Fonctionnement | Avantages | Limites |
|---|---|---|---|
| Single-Agent | Un agent réalise l’ensemble des tâches | Simplicité, contexte centralisé | Responsabilités multiples |
| Multi-Agent | Plusieurs agents se partagent les tâches | Spécialisation, parallélisation possible | Coordination, coûts, complexité |
Quand utiliser plusieurs agents ?#
Une architecture multi-agents devient pertinente lorsque :
- les tâches nécessitent des compétences ou instructions distinctes ;
- les outils et permissions diffèrent selon les responsabilités ;
- certaines tâches peuvent être exécutées indépendamment ;
- le contexte d’un agent unique devient difficile à maîtriser ;
- des vérifications spécialisées apportent un bénéfice mesurable.
Principe : commencer avec un agent unique et introduire plusieurs agents uniquement lorsque leur utilité est démontrée.
3. Principales architectures multi-agents#
Plusieurs patterns permettent d’organiser la collaboration.
| Architecture | Principe | Exemple |
|---|---|---|
| Supervisor / Workers | Un agent central délègue et coordonne | Agent superviseur et agents Data/ML |
| Handoff | Un agent transfère le contrôle à un autre | Agent de triage vers agent spécialisé |
| Sequential | Les agents interviennent successivement | Extraction, analyse, rédaction |
| Parallel | Plusieurs agents travaillent simultanément | Audits indépendants |
| Evaluator / Optimizer | Un agent produit, un autre évalue | Développement et revue de code |
Ces architectures peuvent être combinées dans un même système.
3.1. Supervisor / Workers#
L’architecture Supervisor / Workers repose sur un agent superviseur qui coordonne plusieurs agents spécialisés.
Le superviseur peut :
- Analyser la demande.
- Décomposer le travail.
- Sélectionner les agents appropriés.
- Déléguer les sous-tâches.
- Collecter et vérifier les résultats.
- Produire une synthèse finale.
Exemple en Data Science :
| Agent | Responsabilité |
|---|---|
| Supervisor | Planification et coordination |
| Data Agent | Préparation et qualité des données |
| ML Agent | Entraînement et évaluation |
| QA Agent | Vérification des tests et résultats |
Le superviseur conserve la responsabilité globale du résultat.
3.2. Handoff#
Le Handoff correspond à un transfert de contrôle entre agents.
Contrairement au pattern Supervisor / Workers, l’agent initial peut céder la responsabilité de la suite de l’interaction à un agent spécialisé.
Exemple :
- Un agent général reçoit une demande.
- Il identifie une question relative au déploiement.
- Il transfère le contrôle à un agent DevOps.
- L’agent DevOps poursuit le traitement.
Le handoff est particulièrement adapté aux systèmes disposant de plusieurs domaines fonctionnels.
3.3. Sequential et Parallel#
Deux stratégies permettent d’organiser l’ordre d’exécution.
| Stratégie | Fonctionnement | Exemple |
|---|---|---|
| Sequential | Chaque agent dépend du résultat précédent | Data → ML → Reporting |
| Parallel | Plusieurs agents travaillent indépendamment | Plusieurs audits de code |
| Hybrid | Combinaison d’étapes parallèles et séquentielles | Analyses parallèles puis synthèse |
La parallélisation peut réduire la durée totale, mais uniquement si les tâches sont suffisamment indépendantes.
Des dépendances fortes ou des modifications concurrentes peuvent annuler cet avantage.
4. Délégation et coordination#
La délégation consiste à confier une tâche à un autre agent, tandis que la coordination organise les interactions entre agents.
Les mécanismes de délégation#
| Mécanisme | Description |
|---|---|
| Agents as Tools | Le superviseur appelle un agent spécialisé comme un outil |
| Handoff | Le contrôle est transféré à un autre agent |
| Task Assignment | Une sous-tâche est attribuée à un agent |
| Parallel Dispatch | Plusieurs sous-tâches sont distribuées simultanément |
Dans une architecture Agents as Tools, le superviseur conserve généralement le contrôle de l’interaction et consolide les résultats.
Dans un Handoff, l’agent spécialisé prend le relais.
Définir un contrat de délégation#
Chaque sous-tâche doit idéalement préciser :
- Objective : résultat à obtenir.
- Context : informations nécessaires.
- Scope : périmètre autorisé.
- Constraints : règles et restrictions.
- Output : livrable attendu.
- Validation : critères de réussite.
Exemple :
Agent : Data QA
Objectif :
Vérifier la qualité des données Silver.
Périmètre :
Tables Silver uniquement.
Contraintes :
- Lecture seule.
- Aucune modification des données.
Livrable :
- Anomalies détectées.
- Tests exécutés.
- Recommandations prioritaires.Un contrat de délégation explicite réduit les ambiguïtés et facilite la consolidation des résultats.
5. Gestion du contexte et de l’état#
Chaque agent peut disposer d’un contexte propre.
Cela permet de limiter les informations transmises et de spécialiser les instructions.
| Approche | Fonctionnement |
|---|---|
| Shared Context | Plusieurs agents accèdent à des informations communes |
| Isolated Context | Chaque agent dispose de son propre contexte |
| Selective Context | Seules les informations pertinentes sont transférées |
| Shared State | Les agents consultent ou modifient un état partagé |
Bonnes pratiques#
- Fournir uniquement le contexte nécessaire.
- Définir clairement les responsabilités.
- Éviter les modifications concurrentes des mêmes fichiers.
- Utiliser des formats de sortie structurés.
- Conserver les résultats intermédiaires importants.
- Prévoir des mécanismes de reprise après échec.
Plusieurs agents ne partagent pas automatiquement leur mémoire ou leur état. Ces échanges doivent être organisés par le harness ou l’application.
6. Coordination centralisée ou décentralisée#
Deux grandes approches peuvent être distinguées.
| Approche | Principe | Avantages | Limites |
|---|---|---|---|
| Centralisée | Un superviseur coordonne les agents | Contrôle, cohérence | Risque de goulot d’étranglement |
| Décentralisée | Les agents communiquent ou se passent le contrôle | Flexibilité | Coordination plus complexe |
L’orchestration peut également être :
- Code-driven : les transitions sont définies par le programme.
- LLM-driven : le modèle décide des agents à solliciter.
- Hybrid : certaines décisions sont programmées, d’autres confiées au modèle.
Une orchestration déterministe est préférable lorsque les étapes sont connues et stables.
L’orchestration par LLM devient intéressante lorsque les sous-tâches dépendent fortement du contexte.
7. Exemple : projet Data Science agentique#
Un projet Data Science peut mobiliser plusieurs agents spécialisés.
| Agent | Responsabilité | Livrable |
|---|---|---|
| Supervisor | Organisation et suivi du projet | Plan et synthèse |
| Data Engineering | Collecte, transformations, qualité | Pipeline de données |
| Data Science | EDA, features, modèles | Expérimentations |
| Evaluation | Validation statistique, métriques, robustesse | Rapport d’évaluation |
| Software Engineering | API, application, déploiement | Application fonctionnelle |
Déroulement possible#
- Le superviseur analyse les objectifs.
- L’agent Data Engineering prépare les données.
- L’agent Data Science réalise les expérimentations.
- L’agent Evaluation vérifie les résultats.
- L’agent Software Engineering intègre les composants validés.
- Le superviseur consolide les livrables.
Certaines étapes peuvent être parallélisées lorsque leurs dépendances le permettent.
Limites#
La spécialisation des agents ne garantit pas :
- la qualité des modèles ;
- l’absence de fuite de données ;
- la validité des expérimentations ;
- la cohérence des modifications ;
- la pertinence des conclusions.
Les résultats doivent être vérifiés avec des tests et des critères indépendants des agents.
8. Limites et bonnes pratiques#
| Risque | Bonne pratique |
|---|---|
| Coûts élevés | Limiter le nombre d’agents et d’appels LLM |
| Duplication du travail | Définir des responsabilités distinctes |
| Conflits de modifications | Isoler les espaces de travail ou coordonner les écritures |
| Perte de contexte | Structurer les échanges entre agents |
| Propagation des erreurs | Valider les résultats intermédiaires |
| Coordination complexe | Privilégier une orchestration simple |
| Difficultés de diagnostic | Conserver des traces par agent et par tâche |
Recommandations#
- Commencer avec un agent unique.
- Spécialiser les agents selon des responsabilités réelles.
- Définir un contrat clair pour chaque délégation.
- Paralléliser uniquement les tâches indépendantes.
- Limiter le partage d’informations inutiles.
- Prévoir des mécanismes de validation et de reprise.
- Comparer les performances avec une solution mono-agent.
Le nombre d’agents n’est pas un indicateur de qualité. La pertinence de l’architecture dépend des résultats obtenus, des coûts et de la complexité introduite.
9. Synthèse#
Les architectures multi-agents permettent de répartir des tâches complexes entre plusieurs agents spécialisés.
Les notions essentielles sont :
- Supervisor : agent chargé de coordonner les travaux.
- Worker / Subagent : agent chargé d’une tâche déléguée.
- Delegation : attribution d’une responsabilité à un autre agent.
- Handoff : transfert du contrôle entre agents.
- Agents as Tools : utilisation d’agents spécialisés par un agent principal.
- Orchestration : organisation des interactions et de l’exécution.
- Coordination : gestion des dépendances, échanges et résultats.
Une architecture multi-agents est pertinente lorsque la spécialisation ou la parallélisation apporte un bénéfice supérieur à son coût de coordination.
La solution la plus simple reste généralement préférable tant qu’elle répond correctement aux besoins.
