Systèmes multi-agents : Frameworks et tutoriel étape par étape
Eliott Ardisson
Founder & CEO - Basalt Studio
Comprendre les systèmes multi-agents IA : architecture, frameworks, étapes de mise en œuvre et cas d'usage concrets pour les PME qui veulent automatiser des processus complexes.
Points clés
- Un système multi-agents distribue le travail entre plusieurs agents IA spécialisés plutôt que de surcharger un seul modèle, ce qui améliore la qualité des résultats sur les processus à plusieurs dimensions.
- L’architecture repose sur trois piliers : la spécialisation de chaque agent, les protocoles de communication inter-agents, et la gestion du contexte partagé.
- Les frameworks disponibles (n8n, LangChain, CrewAI, AutoGen) ont des profils très différents — le bon choix dépend de votre équipe technique et de la complexité du workflow ciblé.
- Les systèmes multi-agents ne sont pas adaptés à tous les cas d’usage : pour les tâches simples, un agent unique reste plus économique et plus facile à maintenir.
- La mise en œuvre suit une séquence précise : audit des processus, conception de l’architecture, tests par agent, puis déploiement progressif.
Ce qu’est vraiment un système multi-agents
Un système multi-agents (SMA) est une architecture dans laquelle plusieurs agents IA autonomes collaborent pour accomplir une tâche qu’aucun d’eux ne pourrait traiter efficacement seul. Chaque agent dispose de son propre modèle de langage, de son prompt système, de ses outils et, souvent, de sa propre mémoire de travail. Ils communiquent entre eux selon des protocoles définis et partagent un contexte commun quand c’est nécessaire.
Ce n’est pas un concept théorique réservé aux grandes entreprises technologiques. Un cabinet de recrutement qui automatise la qualification des candidats, une agence comptable qui traite des liasses fiscales, ou un prestataire HVAC qui gère les demandes d’intervention : tous ces cas impliquent des processus à plusieurs étapes, avec des domaines d’expertise distincts, qui se prêtent naturellement à une architecture multi-agents.
La distinction centrale avec un agent unique : là où un agent monolithique doit tout gérer avec un seul prompt et un seul contexte, un SMA distribue les responsabilités. Le résultat, c’est une meilleure qualité sur chaque sous-tâche, une maintenance plus modulaire, et une capacité à faire évoluer le système par blocs plutôt que de tout réécrire.
Agent unique vs système multi-agents : quand choisir quoi
Avant de se lancer dans une architecture complexe, la première question est la bonne : est-ce que ce problème justifie la complexité d’un SMA ?
| Dimension | Agent unique | Système multi-agents |
|---|---|---|
| Architecture | Monolithique | Distribuée |
| Spécialisation | Généraliste | Agents experts par domaine |
| Scalabilité | Verticale (modèle plus puissant) | Horizontale (ajout d’agents) |
| Coût par requête | Plus faible | Plus élevé (plus de tokens) |
| Mode de défaillance | Point unique | Défaillances isolées |
| Maintenance | Prompt unique complexe | Agents modulaires indépendants |
| Latence | Faible | Cumulée à chaque handoff |
Un agent unique reste le bon choix pour des tâches bien délimitées : répondre à une FAQ, rédiger un email de relance, classer un document entrant. Dès que le processus implique plusieurs domaines d’expertise, des décisions conditionnelles complexes, ou un volume de contexte qu’un seul agent ne peut pas maintenir de façon fiable, le multi-agents devient pertinent.
McKinsey a documenté que les entreprises qui déploient l’IA sur des processus métier complets — et non sur des tâches isolées — obtiennent des gains de productivité nettement supérieurs. Les SMA sont précisément l’outil qui permet d’opérer à cette échelle.
Les composants d’un système multi-agents
Les types d’agents et leurs rôles
Dans la majorité des implémentations réelles, on retrouve quatre types d’agents :
Agent routeur : Point d’entrée du système. Il analyse la demande entrante et la dirige vers l’agent spécialisé approprié. Sa logique est souvent simple, ce qui justifie l’usage d’un modèle moins coûteux.
Agents spécialisés : Ce sont les agents “métier”. Un agent facturation qui interroge la base de données comptable, un agent technique qui cherche dans la documentation produit, un agent qualification qui évalue un dossier candidat. Chacun a ses propres outils et son propre prompt system.
Agent coordinateur : Présent dans les architectures plus complexes, il orchestre les interactions entre agents quand une tâche nécessite plusieurs spécialistes en séquence ou en parallèle.
Agent de sortie : Formate la réponse finale, s’assure de la cohérence du message produit par les agents amont, et livre le résultat à l’utilisateur ou au système cible.
La communication inter-agents
Les agents communiquent via des structures de message standardisées. Un passage de contexte typique inclut l’identifiant de l’expéditeur, le destinataire, le type de requête, l’historique de conversation pertinent, et les données spécifiques à la tâche.
Quatre méthodes de communication sont couramment utilisées :
- Appels API synchrones : Pour les échanges rapides où l’agent amont attend la réponse avant de continuer.
- Files de messages asynchrones : Pour les traitements longs ou les pics de charge. RabbitMQ ou des solutions équivalentes gèrent la queue.
- Mémoire partagée : Un cache (Redis, par exemple) accessible par tous les agents pour maintenir le contexte de session.
- Architecture event-driven : Les agents réagissent à des événements système plutôt qu’à des appels directs — utile pour les workflows déclenchés par des changements d’état.
La gestion du contexte
C’est souvent là que les implémentations échouent. Le contexte doit être segmenté en trois niveaux :
- Contexte global : État du système, paramètres de configuration, données d’entreprise partagées.
- Contexte de session : Tout ce qui est spécifique à l’interaction en cours avec un utilisateur ou un dossier donné.
- Contexte d’agent : La mémoire de travail propre à chaque agent pour la sous-tâche qu’il traite.
Ne pas définir clairement cette séparation produit deux symptômes classiques : des agents qui “oublient” ce qui s’est passé en amont, ou au contraire des agents submergés par du contexte non pertinent qui dégrade leurs réponses.
Les étapes de mise en œuvre
Étape 1 — Analyser les processus candidats
Tous les workflows ne justifient pas l’architecture multi-agents. Avant de concevoir quoi que ce soit, identifiez les processus qui cochent ces critères :
- Le processus implique au moins deux domaines d’expertise distincts
- Il existe des points de décision conditionnels significatifs
- Le volume de contexte dépasse ce qu’un agent unique peut gérer de façon fiable
- Il y a un bénéfice réel à traiter certaines branches en parallèle
Concrètement : un cabinet juridique qui traite des demandes entrantes (qualification du dossier, vérification de conflits d’intérêts, assignation à un avocat, génération d’un email de réponse) a un bon candidat. Un simple chatbot de FAQ n’en est pas un.
Étape 2 — Concevoir l’architecture des agents
Définissez pour chaque agent : son domaine de responsabilité, ses outils (quelles APIs, quelles bases de données, quels templates), le modèle utilisé, et les conditions d’activation et de transfert.
Un point souvent négligé : la matrice des transferts. Quel agent peut appeler quel autre agent, sous quelle condition, et avec quel payload ? Documenter cette matrice avant de coder évite des heures de debugging.
Étape 3 — Choisir le framework
Le choix du framework dépend autant de l’équipe que du cas d’usage :
n8n convient aux équipes qui veulent une interface visuelle et des intégrations natives avec des outils tiers (CRM, ERP, messagerie). C’est un point d’entrée accessible, particulièrement adapté aux workflows hybrides humain-agent. Basalt Studio utilise n8n dans de nombreuses implémentations pour les PME non-techniques.
CrewAI est conçu pour les architectures où des agents jouent des “rôles” définis et collaborent sur des objectifs communs. La prise en main est relativement rapide.
AutoGen (Microsoft) offre des patterns de conversation avancés et s’intègre bien dans les environnements Microsoft. La courbe d’apprentissage est plus élevée.
LangChain offre la flexibilité maximale mais aussi la complexité maximale. À réserver aux équipes avec une expérience solide en développement IA.
Pour les implémentations qui s’appuient sur l’API Anthropic (Claude), le SDK TypeScript ou Python s’intègre directement dans n’importe lequel de ces frameworks.
Étape 4 — Développer et tester par agent
Ne testez pas le système entier d’un coup. La méthode correcte :
- Tests unitaires par agent : Chaque agent est validé isolément avec des cas de test représentatifs, incluant les cas limites.
- Tests d’intégration par paire : Vérifiez les transferts entre deux agents avant d’assembler l’ensemble.
- Tests de charge : Évaluez la latence cumulée et la consommation de tokens sous charge réelle.
- Déploiement progressif : Activez les agents en production un par un, sur un sous-ensemble du trafic réel.
Étape 5 — Monitorer et optimiser
Les métriques à suivre dès le premier jour :
- Latence de réponse par agent (pour identifier les goulots d’étranglement)
- Taux d’erreur de communication inter-agents
- Consommation de tokens par interaction complète
- Taux de résolution sans intervention humaine
- Satisfaction utilisateur sur les réponses finales
Un système multi-agents bien conçu doit être observable. Les logs distribués et le tracing des interactions ne sont pas optionnels.
Cas d’usage concrets pour les PME
Cabinet de recrutement : qualification des candidats
Un agent collecteur récupère les candidatures entrantes depuis plusieurs canaux. Un agent qualificateur analyse le profil par rapport aux critères du poste. Un agent vérificateur croise les informations avec les données du CRM. Un agent communicant génère un email de réponse personnalisé et met à jour le dossier dans l’ATS. Ce qui prenait 15 minutes par dossier peut descendre à moins de 2 minutes de traitement humain.
Agence immobilière : traitement des demandes entrantes
Un agent routeur classe les demandes (achat, location, estimation, renseignements). Un agent qualification évalue la solvabilité et les critères de recherche. Un agent matching interroge la base de biens disponibles. Un agent coordinateur programme une visite ou génère une sélection de biens avec une note personnalisée. L’agent humain intervient sur les étapes à valeur ajoutée.
Cabinet comptable : traitement de documents
Un agent de collecte ingère les documents entrants (factures, relevés, liasses). Un agent de classification détermine le type de document et le client associé. Un agent d’extraction récupère les données structurées. Un agent de validation croise avec les données existantes et signale les anomalies. Le comptable n’intervient que sur les cas d’anomalie.
Dans notre travail avec des cabinets de services professionnels, le point de rupture le plus fréquent se situe au niveau de la gestion du contexte entre l’agent de classification et l’agent de validation — c’est là que les données de session sont le plus souvent mal transmises.
Erreurs courantes et comment les éviter
Sur-ingénierie du système : Créer huit agents pour un processus qui en nécessite trois. Commencez simple. Un système avec trois agents bien conçus surpasse systématiquement un système avec huit agents mal coordonnés.
Mauvaise séparation des responsabilités : Des agents qui se chevauchent produisent des doublons ou des contradictions. Chaque agent doit avoir un périmètre clairement délimité.
Contexte insuffisant ou excessif : Transmettre trop peu de contexte produit des réponses incohérentes. En transmettre trop augmente les coûts et dégrade la qualité. Définissez précisément ce qui voyage dans chaque message.
Absence de monitoring : Déployer sans observabilité, c’est découvrir les problèmes via les plaintes utilisateurs. Les dashboards de monitoring doivent être en place avant la mise en production.
Oublier la latence cumulée : Chaque transfert entre agents ajoute de la latence. Sur un système à cinq agents en séquence, avec 2-3 secondes par agent, vous atteignez rapidement 10-15 secondes de temps de réponse total — inacceptable pour certains cas d’usage.
Définitions des termes clés
Agent IA : Programme autonome qui perçoit un contexte, prend une décision, et exécute une action, en utilisant un modèle de langage comme moteur de raisonnement.
Orchestrateur : Agent ou composant système responsable de coordonner l’ordre d’exécution des autres agents et de gérer les dépendances entre tâches.
Context window : Quantité maximale de texte qu’un modèle de langage peut traiter en une seule requête. La limite de context window est l’une des raisons principales de distribuer le travail entre agents.
Handoff : Transfert de contrôle et de contexte d’un agent à un autre. La qualité du handoff détermine la cohérence du système global.
Prompt système : Instructions permanentes données à un agent au début de chaque interaction, définissant son rôle, ses contraintes et son comportement attendu.
Tool use : Capacité d’un agent à appeler des fonctions externes (APIs, bases de données, outils) pour obtenir des informations ou déclencher des actions au-delà de la génération de texte.
Par où commencer
Un système multi-agents bien conçu n’est pas nécessairement complexe. La majorité des implémentations utiles dans une PME tournent autour de trois à cinq agents avec des rôles clairs. Ce qui compte, c’est la rigueur dans la phase de conception — définir les périmètres, les protocoles de communication, et la stratégie de contexte — avant d’écrire la moindre ligne de code.
La question à poser avant de se lancer n’est pas “quel framework utiliser” mais “quel processus, s’il était automatisé proprement, libérerait le plus de capacité dans mon équipe les six prochains mois ?”
Si vous souhaitez explorer comment une architecture multi-agents pourrait s’appliquer à votre contexte spécifique, vous pouvez réserver un appel stratégie IA avec l’équipe Basalt Studio : cal.com/eliott-ardisson-kzq7zs/ai-strategy-call