Conception de notre système de recherche multi-agents

Faire passer ce système multi-agents du prototype à la production nous apprend des leçons clés d'architecture, de conception d'outils et d'ingénierie de prompts. Un système multi-agents, c'est la collaboration d'un ensemble d'agents (des LLMs qui utilisent de façon autonome des outils en boucle). Dans notre outil de recherche, un agent principal construit à partir de la requête utilisateur un plan d'enquête. Il s'appuie sur des outils pour créer des sous-agents parallèles qui effectuent le travail de recherche en simultané. Ces systèmes introduisent de nouveaux défis de coordination, d'évaluation et de fiabilité.

Ce billet condense les principes qui ont fait leurs preuves chez nous — avec l'espoir qu'ils vous aideront à bâtir vos propres systèmes multi-agents.

Pourquoi un système multi-agents ?

La recherche traite des problèmes ouverts dont les étapes ne peuvent se prévoir à l'avance. Il est impossible de « coder en dur » un chemin figé pour explorer des sujets complexes : le processus est intrinsèquement dynamique et tributaire des découvertes. Comme un humain en pleine enquête, le système ajuste continuellement sa démarche au fil des trouvailles et suit des pistes émergentes.

Cette imprévisibilité rend les agents IA particulièrement pertinents pour la recherche : ils doivent pouvoir pivoter, explorer des connexions tangentielles et, sur de nombreux tours, décider de la direction à partir de résultats intermédiaires. Une pipeline linéaire « one-shot » ne suffit pas.

Au cœur d'une recherche, il y a la compression : distiller des insights à partir d'un vaste corpus. Les sous-agents facilitent cette compression en travaillant en parallèle, chacun dans sa propre fenêtre de contexte, sur une facette différente de la question, puis en condensant l'essentiel pour l'agent chef. Ils permettent aussi une séparation des préoccupations : outils, prompts et trajectoires d'exploration distincts réduisent la dépendance au chemin emprunté et encouragent des investigations indépendantes et approfondies.

Dès qu'un certain seuil d'intelligence est atteint, les systèmes multi-agents deviennent un puissant levier d'échelle. À l'image des sociétés humaines qui ont exponentiellement augmenté leur capacité grâce à l'intelligence collective et à la coordination, même des agents très capables restent limités seuls ; en groupe, ils accomplissent bien davantage.

Exemple : pour lister tous les membres des conseils d'administration des sociétés « Information Technology » du S&P 500, le système multi-agents décompose le problème en tâches parallèles pour ses sous-agents, là où l'agent unique, ralenti par des recherches séquentielles, échoue.

Pourquoi ça marche ? Parce que ces architectures dépensent suffisamment de tokens pour résoudre le problème. Dans notre analyse, trois facteurs expliquent 95 % de la variance de performance sur l'évaluation BrowseComp (qui teste la capacité d'agents navigateurs à dénicher des informations difficiles à trouver) : l'usage de tokens à lui seul explique 80 % de la variance, puis viennent le nombre d'appels d'outils et le choix de modèle.

Revers de la médaille : ces architectures consomment beaucoup de tokens. Dans nos données, un agent utilise en moyenne ~4× plus de tokens qu'un échange de chat, et un système multi-agents ~15× plus. Pour rester viables économiquement, elles exigent des tâches dont la valeur justifie ce surcroît de performance.

Architecture de Recherche (vue d'ensemble)

Notre système adopte un patron orchestrateur-travailleurs : un agent chef coordonne et délègue à des sous-agents spécialisés opérant en parallèle.

Lorsqu'une requête arrive, l'agent principal l'analyse, établit une stratégie et lance des sous-agents pour explorer simultanément des aspects complémentaires. Les sous-agents agissent comme des filtres intelligents : ils itèrent sur des outils de recherche (par ex. sur les entreprises d'agents IA en 2025), puis renvoient leurs trouvailles (une liste d'entreprises, dans cet exemple) à l'agent principal, qui compile la réponse finale.

L'approche diffère d'une RAG (Retrieval-Augmented Generation) classique, qui effectue une récupération statique de fragments proches de la requête puis génère la réponse à partir de ces fragments. À l'inverse, notre architecture met en œuvre une recherche multi-étapes qui découvre dynamiquement des informations pertinentes, s'adapte aux nouvelles trouvailles et analyse les résultats pour produire des réponses de haute qualité.

Voici le flux complet : À réception de la requête, le système crée un agent LeadChercheur qui entre dans un cycle itératif de recherche. Il commence par réfléchir à l'approche et sauvegarde son plan en mémoire pour persister le contexte (si la fenêtre dépasse ~200 000 tokens, elle est tronquée ; conserver le plan devient donc critique). Il crée ensuite des sous-agents spécialisés (deux illustrés, nombre variable) avec des tâches précises. Chaque sous-agent mène des recherches web en autonomie, évalue les résultats via une pensée intercalée (interleaved thinking) et renvoie ses conclusions au LeadResearcher. Celui-ci synthétise, décide s'il faut poursuivre (il peut alors créer d'autres sous-agents ou affiner sa stratégie). Une fois l'information suffisante réunie, le système sort de la boucle et transmet l'ensemble au CitationAgent, qui traite documents et rapport pour ancrer les citations aux passages exacts. Le résultat final, avec citations, part à l'utilisateur.

Ingénierie de prompts et évaluations pour agents de recherche

Les systèmes multi-agents se distinguent nettement des agents unitaires, surtout par la complexité de coordination qui grimpe très vite. Nos premiers agents faisaient des bourdes : 50 sous-agents pour une requête simple, des fouilles du web interminables pour des sources inexistantes, ou des distractions mutuelles à force de mises à jour. Chaque agent étant piloté par prompt, l'ingénierie de prompts est devenue notre principal levier d'amélioration. Voici les principes que nous retenons :

1. Pensez comme vos agents. Pour itérer efficacement sur des prompts, il faut comprendre leurs effets. Nous avons bâti des simulations dans notre Console avec les prompts et outils réels du système et avons observé les agents pas à pas. Les modes d'échec sautent aux yeux : poursuivre après avoir assez de résultats, requêtes trop verbeuses, mauvais choix d'outils.
2. Apprenez à l'orchestrateur à déléguer. L'agent principal découpe la requête en sous-tâches et les décrit aux sous-agents : objectif, format de sortie, outils/sources à privilégier et bornes de tâche claires. Sans descriptions détaillées, les agents dupliquent, laissent des trous ou omettent des informations nécessaires.
3. Ajustez l'effort à la complexité. Les agents estiment mal l'effort adéquat ; nous avons donc intégré des règles d'échelle dans les prompts :
   • Fact-finding simple : 1 agent, 3–10 appels d'outils.
   • Comparaisons directes : 2–4 sous-agents, 10–15 appels chacun.
   • Recherche complexe : > 10 sous-agents, responsabilités nettement divisées.
4. La conception et la sélection d'outils sont cruciales. L'interface agent-outil compte autant qu'une interface homme-machine. Choisir le bon outil est souvent nécessaire. Un agent qui cherche sur le web un contexte disponible seulement dans Slack est condamné d'emblée.
5. Laissez les agents s'améliorer eux-mêmes. Les modèles Claude 4 sont d'excellents prompt engineers. Décrivez-leur un prompt et un mode d'échec : ils diagnostiquent et proposent des correctifs. Nous avons même créé un agent testeur d'outils : face à un outil MCP bancal, il tente de l'utiliser puis réécrit sa description.
6. Commencez large, puis resserrez. La stratégie de recherche doit imiter un expert : cartographier le terrain avant d'entrer dans le détail. Les agents ont tendance à lancer des requêtes trop longues et spécifiques qui renvoient peu de résultats. Nous les poussons à démarrer par des requêtes courtes et larges, à évaluer ce qui existe, puis à resserrer progressivement.
7. Guidez le raisonnement. Le mode de pensée étendue (extended thinking) — qui amène le modèle à produire des tokens de réflexion visibles — sert de carnet de notes contrôlable. L'agent principal y planifie son approche, choisit les outils pertinents, évalue la complexité et le nombre de sous-agents, et définit leurs rôles.
8. Les appels d'outils en parallèle changent l'échelle et la vitesse. Les recherches complexes exigent d'explorer beaucoup de sources. Nous avons introduit deux niveaux de parallélisation :

• L'agent principal lance 3–5 sous-agents en parallèle
• Les sous-agents utilisent ≥ 3 outils en parallèle

Ces changements réduisent le temps de recherche jusqu'à –90 % pour des requêtes complexes.

Notre stratégie de prompting privilégie des heuristiques robustes plutôt que des règles rigides. Nous avons observé le travail d'opérateurs humains expérimentés et l'avons encodé : décomposer, évaluer la qualité des sources, adapter la recherche aux trouvailles, arbitrer profondeur vs largeur. Nous posons aussi des garde-fous explicites pour prévenir les dérives.

Évaluer efficacement des agents

De bonnes évaluations sont essentielles à la fiabilité des applications IA, et les agents n'y échappent pas. Mais évaluer des systèmes multi-agents pose des défis singuliers. Les évaluations classiques supposent que l'IA suit toujours les mêmes étapes : entrée X → chemin Y → sortie Z. Or les systèmes multi-agents ne fonctionnent pas ainsi : même en partant du même point, ils peuvent emprunter des chemins différents mais valides.

Commencez tôt avec de petits échantillons. Au début, les changements ont des effets massifs (beaucoup de « low-hanging fruit »). Un simple ajustement de prompt peut faire passer un taux de succès de 30 % à 80 %. Avec un tel effet, quelques dizaines de cas suffisent pour départager les variantes. Nous démarrons avec ~20 requêtes qui reflètent des usages réels — suffisant pour voir nettement l'impact.

L'évaluation « LLM-juge » passe à l'échelle si elle est bien conçue. Les sorties de recherche sont du texte libre, rarement à réponse unique. Les LLMs conviennent pour noter via une grille : exactitude factuelle (les affirmations correspondent-elles aux sources ?), exactitude des citations, exhaustivité, qualité des sources (primaires > secondaires), efficience des outils (bons outils, bon volume).

L'évaluation humaine détecte ce que l'automatique manque. Des testeurs humains révèlent les cas limites : hallucinations sur des requêtes atypiques, défaillances système, biais subtils de sélection de sources. Chez nous, les premiers agents favorisaient des fermes de contenu SEO plutôt que des sources autoritatives (PDF académiques, blogs d'experts). L'ajout d'heuristiques de qualité de source dans les prompts a rectifié le tir.

Les systèmes multi-agents exhibent des comportements émergents : de petits changements côté agent principal modifient de façon imprévisible le comportement des sous-agents. Réussir impose de comprendre les patrons d'interaction, pas seulement les agents isolés.

Fiabilité en production : défis d'ingénierie

Dans un logiciel traditionnel, un bogue casse une fonctionnalité, dégrade des performances ou provoque une panne. Dans un système agentique, de petites modifications peuvent créer de grands écarts de comportement. Écrire du code pour des agents complexes qui doivent maintenir un état sur la durée est remarquablement difficile.

Les agents sont « stateful » et les erreurs se composent. Les agents peuvent tourner longtemps et conserver un état au fil de nombreux appels d'outils ; il faut exécuter durablement du code et gérer les erreurs en chemin. Sans bons mécanismes, de menus incidents deviennent catastrophiques. Redémarrer de zéro coûte cher et frustre ; nous concevons donc des systèmes capables de reprendre là où l'agent s'est arrêté.

Le debugging exige de nouvelles approches. Les agents prennent des décisions dynamiques et restent non déterministes d'une exécution à l'autre, à prompts identiques. Diagnostiquer « l'agent n'a pas trouvé une info évidente » suppose de savoir pourquoi : requêtes mal formées ? mauvaises sources ? échecs d'outil ? En ajoutant une traçabilité complète en production, nous pouvons attribuer les échecs et corriger de façon systématique.

Le déploiement demande une coordination fine. Les systèmes d'agents forment des toiles hautement stateful de prompts, d'outils et de logique d'exécution qui tournent presque en continu. Lors d'une mise à jour, un agent peut se trouver n'importe où dans son processus. Basculer tout le monde d'un coup est impossible. Nous pratiquons des rainbow deployments (déploiements « arc-en-ciel ») pour épargner les agents actifs : trafic transféré progressivement de l'ancienne vers la nouvelle version, en co-exécutant les deux.

L'exécution synchrone crée des goulots d'étranglement. Aujourd'hui, nos agents principaux attendent que chaque fournée de sous-agents ait terminé. La coordination est plus simple, mais cela bloque le flux d'information : l'agent principal ne peut pas piloter en cours de route, les sous-agents ne coordonnent pas entre eux, et tout le système peut être retenu par un sous-agent lent. Une exécution asynchrone offrirait davantage de parallélisme, au prix de défis en agrégation des résultats, cohérence d'état et propagation d'erreur.

Conclusion

Avec les agents IA, le « dernier kilomètre » devient souvent l'essentiel du trajet. Un code qui marche sur la machine du développeur exige beaucoup d'ingénierie pour devenir fiable en production. La composition des erreurs dans des systèmes agentiques signifie qu'un incident mineur pour un logiciel traditionnel peut faire dérailler un agent. Un seul échec peut changer la trajectoire d'exploration et mener à des issues imprévisibles. D'où un fossé entre prototype et production souvent plus large qu'anticipé.

Malgré tout, les systèmes multi-agents se révèlent précieux pour des recherches ouvertes. Des utilisateurs rapportent que l'IA les aide à dénicher des opportunités business insoupçonnées, à naviguer des options santé complexes, à résoudre des bogues techniques coriaces, et à économiser des jours de travail en découvrant des connexions qu'ils n'auraient pas vues seuls.

Avec une ingénierie soignée, des tests complets, un design précis des prompts et des outils, des pratiques opérationnelles robustes et une collaboration étroite entre recherche, produit et ingénierie, bien au fait des capacités actuelles des agents, les systèmes de recherche multi-agents fonctionnent fiablement à l'échelle.