Agents Deep Research : comment fonctionne la recherche autonome

Poser une question complexe à un assistant et recevoir, quelques minutes plus tard, un rapport structuré avec des dizaines de sources : c'est la promesse des agents Deep Research. Proposés par les grands laboratoires d'IA et reproduits par la communauté open source, ces systèmes ne se contentent plus de répondre, ils mènent une véritable enquête sur le web.

Pour un développeur, la question est de savoir ce qui se cache derrière cette expérience. Comment un agent décide-t-il de ce qu'il doit chercher ? Comment lit-il des dizaines de pages sans saturer sa fenêtre de contexte ? Comment garantit-on que les citations du rapport correspondent réellement à des sources existantes ? Autant de défis d'ingénierie que l'on regroupe sous le terme d'agent Deep Research.

Ces agents sont une application directe de l'Agentic AI : un modèle de langage équipé d'outils, qui boucle jusqu'à avoir réuni assez d'informations. Dans cet article, nous allons détailler l'anatomie d'un agent Deep Research, examiner la gestion du contexte, des citations et des coûts, puis construire une version minimale avec LangGraph.

Qu'est-ce qu'un agent Deep Research ?

Un agent Deep Research est un système autonome qui reçoit une question ouverte, la décompose en sous-questions, interroge le web (ou une base documentaire) de façon itérative, lit les pages trouvées et rédige un rapport long et sourcé. Là où un chatbot avec recherche web effectue une ou deux requêtes avant de répondre, un agent Deep Research peut enchaîner plusieurs dizaines de recherches et de lectures, pendant plusieurs minutes.

Les principaux laboratoires proposent aujourd'hui leur propre version de ce mode, par exemple chez OpenAI, Google (dans Gemini) ou Perplexity. Leurs approches diffèrent : OpenAI s'appuie sur un modèle de raisonnement entraîné par apprentissage par renforcement pour naviguer et analyser le web, Gemini repose sur un modèle multimodal qui planifie la recherche avant de la mener, et Perplexity combine plusieurs modèles selon l'étape. Côté open source, le projet Open Deep Research de LangChain, construit sur LangGraph, en propose une architecture de référence que chacun peut lire et adapter.

Malgré ces différences, tous partagent le même squelette fonctionnel :

• Planification : la question est clarifiée puis transformée en plan de recherche
• Recherche : des requêtes sont générées et envoyées à un moteur de recherche
• Lecture : les pages pertinentes sont téléchargées, nettoyées et résumées
• Synthèse : les notes accumulées sont assemblées en un rapport avec citations

Ce découpage rappelle l'architecture Plan-and-Execute, enrichie d'une boucle de décision : après chaque série de lectures, l'agent juge s'il en sait assez ou s'il doit poursuivre.

Anatomie de la boucle de recherche

Clarification et planification

Tout commence par la compréhension du besoin. Une question comme « Quel est l'état de l'art de l'inférence LLM sur GPU ? » est ambiguë : quelle période, quel niveau de détail, quel format de livrable ? Plusieurs implémentations posent donc une ou deux questions de clarification, puis produisent un brief de recherche : un texte reformulé qui sert de référence à toutes les étapes suivantes.

À partir de ce brief, un planificateur génère une liste de sous-questions indépendantes. C'est ici que se joue la qualité du résultat final : un plan trop étroit produit un rapport incomplet, un plan trop large dilue la recherche et fait exploser les coûts. Les implémentations avancées confient cette décision à un superviseur (voir notre article sur le superviseur d'agents) qui choisit s'il faut paralléliser plusieurs sous-agents ou conserver un seul fil de recherche.

Recherche, lecture et réflexion

Pour chaque sous-question, un agent de recherche fonctionne sur le modèle ReAct : il génère une requête, appelle un outil de recherche web via le tool calling, observe les résultats, puis décide de continuer ou de s'arrêter. Les résultats d'un moteur de recherche ne contiennent généralement que des extraits. L'agent doit donc récupérer la page complète, en extraire le texte utile et le condenser avant de le stocker.

Cette étape de condensation est essentielle. Une page web brute représente souvent plusieurs milliers de tokens, dont l'essentiel est du bruit (menus, publicités, pieds de page). Un modèle plus petit et moins coûteux est généralement chargé de produire un résumé orienté vers la sous-question, en conservant l'URL source et les passages clés.

Enfin, de nombreuses architectures ajoutent un outil de réflexion : une étape où l'agent écrit explicitement ce qu'il a appris, ce qui manque encore et s'il doit poursuivre. Cette pause force un raisonnement structuré et évite les boucles de recherches redondantes.

Brief : comparer les moteurs d'inférence open source pour LLM

Sous-question 1 : quelles optimisations mémoire existent (PagedAttention, quantification) ?
  -> recherche -> lecture de 4 pages -> résumé avec sources
  -> réflexion : "manque les benchmarks de débit"
  -> recherche -> lecture de 3 pages -> résumé avec sources
  -> réflexion : "couverture suffisante" -> fin

Sous-question 2 : quels critères de choix en production ?
  -> ...

Synthèse et rédaction du rapport

Une fois la recherche terminée, un dernier appel au LLM reçoit le brief et l'ensemble des notes condensées, puis rédige le rapport. Ce choix d'une rédaction en une seule passe, à partir de notes déjà nettoyées, produit en pratique des textes plus cohérents que l'écriture progressive section par section, car le modèle dispose d'une vue d'ensemble de toutes les informations collectées.

À lire : découvrez notre formation Agentic AI

Gérer le contexte et les citations

Le contexte, ressource limitée

Une session de Deep Research manipule rapidement des centaines de milliers de tokens de pages web. Même avec les fenêtres de contexte actuelles, tout accumuler dans une seule conversation dégrade la qualité des réponses : le modèle se perd, ignore des informations au milieu du contexte et coûte plus cher à chaque tour. C'est un cas d'école de context engineering.

Les architectures sérieuses combinent plusieurs techniques :

• Isolation : chaque sous-agent travaille dans son propre contexte et ne renvoie au superviseur qu'un résumé compact
• Compression : les pages sont résumées dès leur lecture, le texte brut n'est jamais conservé dans la conversation
• Stockage externe : les notes et les sources sont écrites dans l'état du graphe ou dans un système de fichiers plutôt que dans l'historique de messages
• Budget d'itérations : un nombre maximal de recherches par sous-agent évite les dérives

Ces mécanismes rejoignent ceux de la mémoire des agents IA, appliqués ici à une tâche unique mais très gourmande en information.

Citations et hallucinations de sources

Le point faible le plus sérieux de ces agents concerne les sources. Un rapport avec quarante références donne une impression de rigueur, mais cette impression est trompeuse si les citations ne sont pas vérifiées. Les défaillances typiques sont les suivantes :

• URL inventée : le modèle fabrique un lien plausible qui n'existe pas
• Citation décorative : la source existe mais ne contient pas l'affirmation qu'on lui attribue
• Source de faible qualité : un blog de contenu généré est traité comme une référence
• Information périmée : une page ancienne est présentée comme l'état actuel

La parade principale consiste à ne jamais laisser le modèle écrire une URL de mémoire. Chaque note de lecture porte un identifiant de source généré par le code, et le rapport final référence uniquement ces identifiants, qui sont ensuite remplacés par les URL réelles. Une étape de vérification peut compléter ce dispositif : un second modèle, dans une logique de LLM-as-a-judge, contrôle que chaque affirmation clé est bien soutenue par le passage cité.

Construire un agent Deep Research minimal avec LangGraph

LangGraph se prête bien à ce cas d'usage, car il modélise la boucle comme un graphe avec un état partagé et permet de paralléliser les sous-questions grâce à l'API Send. Voici une version volontairement réduite : un nœud de planification, un nœud de recherche exécuté en parallèle pour chaque sous-question, puis un nœud de rédaction.

Commençons par l'état, le plan et les outils :

import operator
from typing import Annotated, TypedDict

from langchain.chat_models import init_chat_model
from langchain_tavily import TavilySearch
from pydantic import BaseModel, Field

llm = init_chat_model("openai:gpt-4.1")
cheap_llm = init_chat_model("openai:gpt-4.1-mini")
search = TavilySearch(max_results=4)


class Plan(BaseModel):
    """Plan de recherche : une liste de sous-questions indépendantes."""
    questions: list[str] = Field(description="3 à 5 sous-questions")


class State(TypedDict):
    question: str
    questions: list[str]
    # Chaque branche parallèle ajoute ses notes, d'où le reducer
    notes: Annotated[list[dict], operator.add]
    report: str

Le champ notes utilise un reducer (operator.add) : sans lui, les branches parallèles écriraient sur la même clé et LangGraph lèverait une erreur de mise à jour concurrente. Passons aux nœuds de planification et de recherche :

from langgraph.types import Send


def plan(state: State) -> dict:
    """Décompose la question en sous-questions."""
    planner = llm.with_structured_output(Plan)
    result = planner.invoke(
        f"Décompose cette question en sous-questions de recherche : {state['question']}"
    )
    return {"questions": result.questions}


def dispatch(state: State) -> list[Send]:
    """Lance un nœud de recherche par sous-question, en parallèle."""
    return [Send("research", {"sub_question": q}) for q in state["questions"]]


def research(payload: dict) -> dict:
    """Cherche, puis résume chaque page avec un modèle économique."""
    q = payload["sub_question"]
    results = search.invoke({"query": q})["results"]
    notes = []
    for r in results:
        summary = cheap_llm.invoke(
            f"Résume en 5 phrases ce qui répond à « {q} » :\n{r['content']}"
        ).content
        notes.append({"question": q, "url": r["url"], "summary": summary})
    return {"notes": notes}

La fonction dispatch renvoie une liste d'objets Send : LangGraph crée alors autant de branches research que de sous-questions, exécutées en parallèle. Notez que l'URL provient directement de l'outil de recherche et non du modèle, ce qui supprime le risque d'URL inventée. Il reste à rédiger le rapport et à assembler le graphe :

from langgraph.graph import END, START, StateGraph


def write(state: State) -> dict:
    """Rédige le rapport en citant uniquement les sources collectées."""
    sources = "\n".join(
        f"[{i}] {n['url']}\n{n['summary']}" for i, n in enumerate(state["notes"], 1)
    )
    report = llm.invoke(
        f"Question : {state['question']}\n\nSources :\n{sources}\n\n"
        "Rédige un rapport structuré. Cite chaque affirmation avec [n] "
        "et n'utilise que les sources fournies."
    ).content
    return {"report": report}


builder = StateGraph(State)
builder.add_node("plan", plan)
builder.add_node("research", research)
builder.add_node("write", write)
builder.add_edge(START, "plan")
builder.add_conditional_edges("plan", dispatch, ["research"])
builder.add_edge("research", "write")
builder.add_edge("write", END)
graph = builder.compile()

result = graph.invoke({"question": "Comparer vLLM et SGLang pour servir des LLM"})
print(result["report"])

Cette version pose les fondations, mais elle est linéaire : il n'y a qu'un seul tour de recherche. Pour s'approcher d'un vrai agent Deep Research, il faut ajouter un nœud de réflexion qui évalue si les notes couvrent le brief et, si besoin, renvoie vers la recherche avec de nouvelles sous-questions grâce à une arête conditionnelle. On ajoute aussi un plafond d'itérations, un checkpointing pour reprendre une session interrompue et, pour les missions sensibles, une validation humaine du plan (voir human-in-the-loop).

Coûts, limites et bonnes pratiques

Un agent Deep Research est par nature coûteux : chaque sous-question déclenche plusieurs recherches, chaque page lue un appel de résumé, et le rapport final un appel sur un contexte volumineux. Les mesures décrites dans notre article sur le coût des agents IA s'appliquent pleinement. Le tableau suivant résume les principaux leviers.

L'ordre de grandeur reste élevé par rapport à une simple requête : une session peut mobiliser des centaines de milliers de tokens et durer plusieurs minutes. Il est donc judicieux de réserver ce mode aux questions qui le justifient, et de proposer un mode rapide pour les autres.

Au-delà du coût, plusieurs limites méritent d'être connues :

• Biais du web : l'agent ne voit que ce que le moteur de recherche lui renvoie, avec une surreprésentation des contenus optimisés pour le référencement
• Accès restreint : les contenus derrière un paywall ou une authentification sont inaccessibles
• Confiance excessive : un rapport fluide et bien présenté peut masquer des erreurs de fond
• Injection de prompt : une page web peut contenir des instructions malveillantes que l'agent lira comme du contexte (voir les guardrails pour agents IA)

Pour fiabiliser un tel système, il faut l'évaluer comme n'importe quel agent : jeux de questions de référence, vérification automatique des citations, suivi des traces et des coûts. Notre article sur l'évaluation des agents détaille cette démarche.

À découvrir : notre formation Agentic AI

Conclusion

Les agents Deep Research illustrent ce que l'Agentic AI sait faire de mieux : décomposer un problème ouvert, utiliser des outils de façon itérative et produire un livrable exploitable. Leur architecture repose sur quelques briques simples (planification, recherche, lecture, synthèse), mais la qualité du résultat dépend des détails d'ingénierie : isolation et compression du contexte, citations générées par le code plutôt que par le modèle, et maîtrise des coûts.

Construire une version minimale avec LangGraph est un excellent moyen de comprendre ces mécanismes. Le passage à un système fiable demande ensuite de traiter sérieusement les hallucinations de sources, l'évaluation et la sécurité, car un rapport convaincant n'est pas pour autant un rapport exact.

À mesure que ces agents s'installent dans les pratiques de veille, d'analyse et de documentation, savoir en concevoir, en auditer et en limiter les dérives devient une compétence différenciante pour les développeurs et les AI Engineers.