Cas d'usage multi-agents
Mis à jour le 28 juillet 2026
Du concept à la réalité
Vous maîtrisez les handoffs, les modes d’exécution et le chaînage. Cette leçon assemble ces briques dans trois systèmes complets, chacun bâti sur une topologie différente : une escalade, un pipeline, un routeur. En les lisant, portez attention à la manière dont l’architecture découle du problème et non l’inverse — c’est la nature du besoin qui impose la forme, pas la technologie.
Cas 1 : le support client multi-niveaux
Un service de support fonctionne par paliers : la majorité des demandes se règle au premier contact, une minorité exige un diagnostic technique, une poignée finit chez un humain. Cette réalité se traduit directement en chaîne d’escalade, chaque niveau ne transférant qu’au suivant.
from mistralai import Mistral
import os
client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])
# Niveau 1 : FAQ et questions simples
level1 = client.beta.agents.create(
model="mistral-medium-latest",
name="support-level1",
description="Support niveau 1 : FAQ, questions courantes, informations de base.",
instructions="""Vous êtes le premier niveau de support.
- Répondez aux questions simples (horaires, tarifs, FAQ)
- Si la question est technique ou complexe, transférez au niveau 2
- Soyez poli et professionnel""",
tools=[{"type": "document_library", "library_ids": ["faq-library-id"]}]
)
# Niveau 2 : Support technique
level2 = client.beta.agents.create(
model="mistral-large-latest",
name="support-level2",
description="Support technique : diagnostic, dépannage, configuration.",
instructions="""Vous êtes le support technique.
- Diagnostiquez les problèmes techniques
- Proposez des solutions étape par étape
- Si le problème nécessite une intervention manuelle, transférez au niveau 3""",
tools=[{"type": "web_search"}, {"type": "code_interpreter"}]
)
# Niveau 3 : Escalade humaine (simulation)
level3 = client.beta.agents.create(
model="mistral-large-latest",
name="support-level3",
description="Escalade : problèmes critiques nécessitant une intervention humaine.",
instructions="""Préparez un résumé du problème pour l'équipe technique :
- Contexte du problème
- Étapes de diagnostic effectuées
- Solutions tentées
- Recommandation"""
)
# Chaîner les escalades
level1 = client.beta.agents.update(agent_id=level1.id, handoffs=[level2.id])
level2 = client.beta.agents.update(agent_id=level2.id, handoffs=[level3.id])Deux décisions méritent d’être relevées. Le niveau 1 tourne sur mistral-medium-latest alors que les niveaux suivants utilisent mistral-large-latest : c’est le niveau qui absorbe le plus gros volume, et lui affecter le modèle le plus coûteux reviendrait à payer une expertise inutile sur des questions d’horaires. Le niveau 3, ensuite, ne résout rien : il rédige un dossier. C’est exactement ce qu’on attend d’une escalade vers un humain — l’ingénieur qui prend le relais reçoit le contexte, les étapes de diagnostic déjà effectuées et les solutions déjà tentées, au lieu de recommencer l’interrogatoire depuis zéro.
Concrètement, un client écrit « je n’arrive pas à me connecter à mon compte ». Le niveau 1 consulte la FAQ, n’y trouve pas de cas correspondant et transfère. Le niveau 2 diagnostique et identifie un problème de base de données, hors de sa portée, et transfère à son tour. Le niveau 3 prépare le ticket avec l’intégralité de l’historique.
Cas 2 : le pipeline de veille stratégique
Ici l’ordre est fixe et connu d’avance : on ne peut pas analyser ce qui n’a pas été collecté, ni rédiger ce qui n’a pas été analysé. La chaîne linéaire s’impose donc, et le point d’entrée n’est pas un routeur mais le premier maillon.
# Collecteur — recherche les informations brutes
collector = client.beta.agents.create(
model="mistral-large-latest",
name="intelligence-collector",
description="Collecte d'informations stratégiques via recherche web.",
instructions="""Recherchez des informations sur le sujet demandé.
- Couvrez plusieurs sources
- Incluez les données chiffrées
- Notez les dates de publication""",
tools=[{"type": "web_search"}]
)
# Analyste — extrait les insights
analyst = client.beta.agents.create(
model="mistral-large-latest",
name="intelligence-analyst",
description="Analyse et extraction d'insights à partir de données brutes.",
instructions="""Analysez les données collectées :
- Identifiez les tendances
- Repérez les opportunités et les menaces
- Quantifiez quand possible""",
tools=[{"type": "code_interpreter"}]
)
# Rédacteur — produit le rapport
reporter = client.beta.agents.create(
model="mistral-large-latest",
name="intelligence-reporter",
description="Rédaction de rapports de veille structurés.",
instructions="""Rédigez un rapport de veille professionnel :
## Résumé exécutif (3 phrases)
## Faits clés (bullet points)
## Analyse (2-3 paragraphes)
## Recommandations (actions concrètes)
## Sources"""
)
# Pipeline
collector = client.beta.agents.update(agent_id=collector.id, handoffs=[analyst.id])
analyst = client.beta.agents.update(agent_id=analyst.id, handoffs=[reporter.id])
# Lancer
response = client.beta.conversations.start(
agent_id=collector.id,
inputs="Veille stratégique : marché de l'IA souveraine en Europe, T1 2026."
)Le plan du rapport est écrit noir sur blanc dans les instructions du rédacteur, jusqu’au nombre de phrases du résumé exécutif. Ce niveau de précision est ce qui rend une veille exploitable dans la durée : tous les rapports sortent au même format, ce qui permet de les comparer d’une semaine à l’autre et de les diffuser sans retouche. Notez aussi la consigne donnée au collecteur de relever les dates de publication — sans elle, une veille peut sembler solide tout en s’appuyant sur des sources périmées.
Cas 3 : l’assistant polyvalent
Quand les demandes relèvent de compétences sans lien entre elles, il n’y a ni escalade ni pipeline : il y a un aiguillage. Le routeur central lit la requête et l’envoie à l’un de ses quatre spécialistes, dont aucun n’a besoin de connaître les autres.
# Spécialistes
web_researcher = client.beta.agents.create(
model="mistral-large-latest",
name="web-researcher",
description="Recherche d'informations actuelles sur Internet.",
tools=[{"type": "web_search"}]
)
data_analyst = client.beta.agents.create(
model="mistral-large-latest",
name="data-analyst",
description="Analyse de données, statistiques et visualisations.",
tools=[{"type": "code_interpreter"}]
)
doc_expert = client.beta.agents.create(
model="mistral-large-latest",
name="doc-expert",
description="Interrogation et synthèse de documents internes.",
tools=[{"type": "document_library", "library_ids": ["docs-lib-id"]}]
)
creative = client.beta.agents.create(
model="mistral-large-latest",
name="creative-agent",
description="Création de contenu visuel et illustrations.",
tools=[{"type": "image_generation"}]
)
# Routeur central
assistant = client.beta.agents.create(
model="mistral-large-latest",
name="research-assistant",
description="Assistant de recherche polyvalent.",
instructions="""Vous êtes un assistant de recherche. Analysez chaque requête et transférez au spécialiste approprié :
- Informations actuelles → web-researcher
- Calculs et données → data-analyst
- Questions sur nos documents → doc-expert
- Besoin d'illustrations → creative-agent""",
handoffs=[web_researcher.id, data_analyst.id, doc_expert.id, creative.id]
)Chaque spécialiste porte exactement un outil, et les quatre descriptions ne se recouvrent nulle part. C’est cette absence de chevauchement qui rend le routage stable : si deux agents pouvaient plausiblement traiter la même demande, le choix varierait d’une exécution à l’autre et vos utilisateurs constateraient une qualité inégale sans comprendre pourquoi.
Ce qui distingue une maquette d’un système
Ces trois systèmes partagent la même règle de conception : un agent, une responsabilité. Dès qu’un agent cumule deux rôles, ses instructions se contredisent et sa description devient trop floue pour que le routeur décide correctement. Écrivez donc chaque description en pensant à la décision qu’elle doit permettre, et chaque jeu d’instructions en énonçant aussi ce que l’agent ne doit pas faire.
Le passage en production ajoute quatre exigences que la maquette ignore. La journalisation, d’abord : le mode client vous permet de tracer chaque handoff avec vos propres identifiants, ce qui sera votre seul recours le jour où un utilisateur signalera une réponse aberrante. Les timeouts ensuite, indispensables sur les chaînes longues où un maillon bloqué immobilise tout le reste. Les fallbacks, parce que la question « que se passe-t-il si cet agent échoue ? » doit avoir une réponse écrite avant la mise en ligne, pas après le premier incident. Le suivi des coûts enfin : une chaîne de trois agents consomme des tokens à chaque relais, et seul un compteur par conversation vous dira si votre pipeline de veille coûte quelques centimes ou beaucoup plus.
Points clés à retenir
- Le support client multi-niveaux est un cas d’usage naturel pour les handoffs
- Les pipelines de veille (collecte → analyse → rédaction) exploitent le chaînage linéaire
- Les assistants polyvalents utilisent un routeur central vers des spécialistes
- En production : logging, timeouts, fallbacks et monitoring des coûts sont essentiels
- Un agent = une responsabilité, avec une description précise pour le routage