Choisir entre un agent unique et un système multi-agent dépend de la tâche. Un guide pratique pour comprendre la méthode ReAct et concevoir des agents IA modulaires.

QU'EST-CE QU'UN AGENT IA ?

Les agents d'intelligence artificielle sont devenus incontournables car les grands modèles de langage (LLM) excellent désormais dans des domaines variés : programmation, rédaction, raisonnement, résolution de problèmes. Cette maturité a déplacé l'attention du Développement de modèles sur mesure vers la construction d'applications pratiques autour des LLM existants. Des outils comme Codex, Claude Code, Cursor ou Windsurf aident les ingénieurs logiciels à accélérer leur travail, tandis que les entreprises déploient des agents pour le support client, l'automatisation ou d'autres cas concrets.

Un agent IA est une application qui utilise un LLM pour raisonner, planifier et recourir à des outils afin d'exécuter des tâches, en interagissant avec son environnement de manière utile. À la différence d'un chatbot basique qui suit un chemin direct requête utilisateur → LLM → réponse, un agent va plus loin. Il réfléchit à la tâche, décide des actions nécessaires, choisit les outils à solliciter, en exploite les résultats et poursuit jusqu'à produire une réponse satisfaisante.

Les composants majeurs de la plupart des agents sont au nombre de trois : le LLM, les outils et la mémoire.

LE CYCLE RAISONNEMENT-ACTION : REACT

L'acronyme ReAct signifie Reasoning + Acting (raisonnement + action). Il s'agit d'un patron de conception où le LLM raisonne sur une tâche puis agit, le plus souvent en appelant des outils, en fonction de ce raisonnement. Le cœur de l'approche consiste à bâtir une boucle logique autour du LLM.

Étape 1 : réception de la requête. Le LLM analyse la tâche, évalue s'il peut répondre directement ou s'il doit s'appuyer sur des outils. Il vérifie les outils disponibles et détermine lesquels seront nécessaires.

Étape 2 : appel des outils. L'agent passe à l'action en sollicitant les outils retenus. Ceux-ci peuvent chercher sur le web, récupérer des documents dans une base de données vectorielle, accéder à des fichiers, exécuter du code ou interroger une API externe. Les résultats renvoyés sont appelés sorties d'outils.

Étape 3 : retour des sorties au LLM. Les informations collectées sont transmises au LLM comme contexte additionnel. L'agent dispose ainsi d'éléments plus riches qu'avec la seule requête initiale.

Étape 4 : vérification des preuves et génération de la réponse. Le LLM examine les sorties d'outils et juge si elles suffisent à résoudre la tâche. Si les preuves sont suffisantes, il produit une réponse fondée. Sinon, l'agent peut répéter la boucle raisonnement, appel d'outils et observation jusqu'à obtenir assez d'information.

AGENT UNIQUE OU SYSTÈME MULTI-AGENT ?

La conception structurelle offre deux grandes familles : l'agent unique et le système multi-agent.

Un agent unique confie l'intégralité de la tâche à un seul LLM. Il raisonne, planifie et appelle les outils quand c'est nécessaire. La plupart des projets démarrent ainsi car cette architecture est plus simple, plus facile à maintenir et souvent suffisante.

Un système multi-agent répartit le travail entre plusieurs agents spécialisés. Il s'articule généralement autour d'un agent central, l'orchestrateur (ou superviseur, planificateur), qui coordonne les autres et décide à quel moment chaque agent doit intervenir. Chaque agent dédié possède son propre rôle, ses propres outils et sa propre logique de raisonnement, rendant l'ensemble plus modulaire et adapté aux workflows complexes.

Un agent unique convient aux tâches simples avec peu d'étapes et d'outils. Un système multi-agent s'impose dès lors qu'il faut des rôles spécialisés, un raisonnement en plusieurs étapes, une vérification poussée ou une coordination entre différents outils.

QUAND ADOPTER UNE ARCHITECTURE MULTI-AGENT

Un agent unique peut rapidement se retrouver submergé quand la tâche mobilise de nombreux outils, exige un raisonnement enchaîné, des responsabilités hétérogènes ou une vérification avant la réponse finale. Parmi les problèmes courants, on note une invite surchargée, un mauvais aiguillage des outils, des responsabilités floues et une fiabilité moindre due à une trop grande complexité concentrée dans un seul agent.

Un système multi-agent devient pertinent quand la tâche risquerait de déborder un agent unique et que l'on a besoin d'agents spécialisés aux rôles bien définis, dotés de leurs propres outils et de responsabilités distinctes.

Deux exemples concrets illustrent cet avantage :

Orchestrateur → Codeur → Testeur → Réviseur

Pour un agent d'ingénierie logicielle, l'orchestrateur coordonne le flux, l'agent Codeur génère le code, l'agent Testeur vérifie qu'il fonctionne et l'agent Réviseur contrôle la solution pour déceler des lacunes ou des améliorations possibles.

Orchestrateur → Récupérateur → Rédacteur → Vérificateur

Pour un agent de recherche chargé d'explorer un sujet, de tirer des informations de différentes sources et de produire un contenu étayé, le Récupérateur collecte les données sur le web et dans les documents locaux stockés en base vectorielle, le Rédacteur rédige à partir de ces contenus, et le Vérificateur contrôle les erreurs, les citations et l'exactitude factuelle avant la réponse finale.

Ces systèmes gagnent en modularité et en clarté des rôles. Toutefois, ils n'ont de sens que lorsque la tâche l'exige vraiment, car ils entraînent généralement une augmentation de la latence, des coûts et de la complexité de maintenance en raison d'un plus grand nombre d'appels au LLM et de parties mobiles.

PROJET CONCRET : MULTI-AGENT RAG RESEARCHER

Pour rendre l'idée des systèmes multi-agents plus tangible, le projet Multi-Agent RAG Researcher a été développé. Son objectif : montrer comment un agent central peut coordonner plusieurs agents spécialisés pour rechercher un sujet, extraire des preuves de documents et du web, rédiger un contenu fondé sur des sources et le vérifier avant de le restituer à l'utilisateur. Au lieu de tout faire avec un seul agent, le système répartit le workflow en différentes responsabilités.

Le code est accessible sur GitHub : https://github.com/ayoolaolafenwa/multi-agent-rag-researcher

git clone https://github.com/ayoolaolafenwa/multi-agent-rag-researcher.git

Une fois le dépôt cloné, la structure du projet se présente ainsi :

.
├── docs/                         # Fichiers PDF par défaut
├── memory/                       # Gestion de la mémoire de session (SQLite)
├── qdrantvectordatabase/       # Ingestion PDF et recherche par similarité
├── ui/                           # Application Gradio et gestionnaires UI
├── utils/
│   ├── requirements.txt          # Dépendances Python
├── worker_agents/                # Récupérateur, rédacteur et vérificateur
├── orchestrator_agent.py         # Coordinateur principal
└── run_orchestrator.py           # Point d'entrée CLI

SOURCES DE DONNÉES

Le projet s'appuie sur deux sources majeures :

  • Des documents PDF : leur ingestion, le découpage en fragments (chunks), la vectorisation et la recherche par similarité sont gérés par qdrantvectordatabase/vector_store.py, avec la base vectorielle Qdrant.
  • Le web : l'API Tavily permet de récupérer des informations récentes ou externes.

LES AGENTS SPÉCIALISÉS

L'agent Récupérateur (code dans worker_agents/retriever.py) mobilise Tavily pour la recherche web et interroge la base vectorielle pour les documents locaux. Il utilise le modèle gpt-5.4-mini avec un niveau de raisonnement faible.

L'agent Rédacteur (code dans worker_agents/writer.py) reçoit le contenu collecté et produit un texte de synthèse. Il exploite gpt-5.4 avec un raisonnement faible.

L'agent Vérificateur (code dans worker_agents/verifier.py) contrôle l'exactitude factuelle, les citations et les éventuelles erreurs. Il fonctionne lui aussi avec gpt-5.4 en raisonnement faible.

MÉMOIRE DE SESSION

Pour assurer une cohérence à court terme, le système utilise SQLite. Pour un identifiant de session donné, il stocke les questions précédentes, les réponses et les preuves récupérées. Ainsi, l'orchestrateur peut réutiliser des informations pertinentes lors de questions complémentaires, sans avoir à tout interroger à nouveau. Le module de mémoire se trouve dans memory/memory.py.

LE RÔLE DE L'ORCHESTRATEUR

L'orchestrateur (code dans orchestrator_agent.py, modèle gpt-5.4-mini) coordonne les trois agents travailleurs. Il intègre également un garde-fou : le système se concentre exclusivement sur les questions de recherche et factuelles. Il refuse les tâches généralistes comme l'aide au codage ou un simple calcul mental, car sa mission est d'agir en tant qu'assistant de recherche.

Note : il est possible de remplacer les modèles gpt-5.4 des agents par n'importe quel modèle proposé par OpenAI.

MISE EN ROUTE DU PROJET

1. Créer et activer un environnement virtuel

python3 -m venv env
source env/bin/activate

2. Installer les dépendances

cd multi-agent-rag-researcher
pip3 install -r utils/requirements.txt

3. Configurer les clés API

Créer un fichier utils/var.env avec :

OPENAIAPIKEY=youropenaiapi_key
TAVILYAPIKEY=yourtavilyapi_key

4. Placer les PDF à indexer

Déposez vos fichiers dans le dossier docs/, ou importez-les ultérieurement via l'interface. Le projet inclut déjà Gemma 3 Technical Report.pdf et DeepSeek-V3.2.pdf que vous pouvez utiliser directement ou remplacer.

5. Lancer la version en ligne de commande

python3 run_orchestrator.py

Au démarrage, la CLI ingère les PDF du dossier docs/ dans la base Qdrant locale. Tapez q ou exit pour terminer la session.

6. Lancer l'interface graphique (Gradio)

python3 ui/gradio_app.py

L'interface charge automatiquement les PDF par défaut au démarrage. Si vous téléversez de nouveaux fichiers, ils remplacent l'ensemble de documents indexés pour la session en cours.

CE QU'IL FAUT RETENIR

Cet article a expliqué le fonctionnement d'un agent IA, la manière dont il utilise des outils pour interagir avec son environnement, et comment l'approche ReAct l'aide à raisonner, planifier, sélectionner les outils et exécuter des tâches spécifiques. Il a également détaillé les deux conceptions structurelles, agent unique ou multi-agent, et comparé leurs cas d'usage respectifs.

Enfin, une visite guidée du projet Multi-Agent RAG Researcher a montré comment un orchestrateur coordonne trois agents spécialisés, récupère des informations du web et de documents locaux, s'appuie sur une mémoire pour la cohérence, produit et vérifie un contenu étayé avant de fournir la réponse finale.

Sources :
  • Towards Data Science

L'indépendance de CLODCO est votre garantie.

Pour que l'actualité de l'IA reste sans filtre et sans concession, votre soutien est indispensable. Votre contribution est le seul moteur de notre liberté éditoriale.

Soutenir CLODCO