Le nouvel outil Deep Research de Claude peut traiter 6,57 millions de tokens en un seul appel — une prouesse que seul un budget de calcul massif peut soutenir. Le système n'est pas un modèle de langage monolithique ; il fonctionne comme un pipeline map-reduce JavaScript strict qui déploie des recherches, récupère des données, confronte les affirmations à trois vérificateurs indépendants, puis synthétise un rapport.

Pourquoi l'architecture est importante

La plupart des assistants de recherche alimentés par l'IA présentent une interface unique de type « question-réponse », laissant le modèle générer du texte et des citations en une seule fois. Le Deep Research de Claude renverse ce modèle. Il décompose la tâche en étapes discrètes et typées, et force le modèle à obéir à un harness (cadre logiciel). Les concepteurs l'ont conçu pour limiter les hallucinations tout en fournissant des réponses riches et sourcées. Cette approche est issue d'un framework de recherche automatisée de bugs, où une hypothèse est générée, puis délibérément tentée d'être infirmée. En termes de recherche, une affirmation naît, puis trois agents adverses tentent de l'éliminer avant qu'elle n'atteigne la synthèse finale.

Le flux map-reduce

  1. Recherche par déploiement (Fan-out search) – L'orchestrateur génère des travailleurs parallèles qui interrogent une gamme de sources de données.
  2. Récupération des données (Fetch data) – Chaque travailleur extrait des extraits bruts, des métadonnées et toute information structurée disponible.
  3. Vérification adverse (Adversarial verification) – Trois agents indépendants reçoivent chaque affirmation, chacun ayant pour instruction de choisir par défaut réfutée en cas d'incertitude. L'affirmation ne survit que si elle recueille suffisamment de votes affirmatifs.
  4. Synthèse (Synthesis) – Les affirmations survivantes sont assemblées dans un rapport JSON final que l'utilisateur peut restituer sous forme de texte.

Au cœur du harness

Le harness est une fine couche de code qui définit ce que le modèle de langage est autorisé à faire. Ses règles se présentent sous la forme d'un ensemble de tâches structurées :

  • SCOPE – Le modèle reçoit une description concise de la question de recherche.
  • SEARCH – Il doit émettre une liste d'identifiants de sources, et jamais de texte libre.
  • EXTRACT – Pour chaque source, le modèle renvoie une citation textuelle exacte qui appuie toute affirmation ultérieure.
  • VERDICT – Il produit un objet JSON contenant l'affirmation, la citation de soutien et un score de confiance.
  • REPORT – L'étape finale regroupe toutes les affirmations vérifiées dans un document unique.

Le harness impose le liage de preuves (evidence binding) : une affirmation sans citation exacte est automatiquement rejetée. Il expose également des constantes de politique (policy constants) qui peuvent être ajustées sans modifier le code — le nombre de votes affirmatifs nécessaires pour une affirmation, le nombre de sources que le système peut lire, ou le nombre maximum d'affirmations passant à la vérification.

Une étape de triage se situe entre l'extraction et la vérification. Au lieu d'envoyer chaque affirmation aux coûteux agents adverses, le système les classe par importance et par qualité de source, puis ne transmet que les 25 meilleures. Ce tri évite que l'utilisation des tokens et les coûts de calcul ne deviennent incontrôlables.

La vérification adverse en pratique

L'étape de vérification est délibérément sévère. Chacun des trois agents reçoit la même affirmation et sa citation source, puis opère selon un ensemble d'instructions lui demandant de supposer que l'affirmation est fausse, à moins qu'il ne trouve une preuve décisive. Si un agent a un doute, il vote réfutée. L'affirmation doit recueillir un nombre configurable de votes confirmés pour survivre.

Lors de tests informels, la couche adverse a détecté une affirmation qui interprétait par erreur une métrique agrégée comme un score de précision spécifique. Le modèle avait généré une déclaration assurée sur la précision, alors que la source ne rapportait qu'une métrique agrégée.

Ce que la conception révèle sur la construction de systèmes d'IA

  1. Séparer le contrôle du raisonnement – Le modèle reste responsable de l'inférence ; le harness impose la discipline du processus.
  2. Les interfaces typées réduisent les hallucinations – En exigeant une sortie JSON et des citations exactes, le système élimine la dérive du texte libre.
  3. Le filtrage des affirmations avant l'étape de vérification coûteuse réduit l'utilisation des tokens et les coûts de calcul.
  4. Traiter les entrées externes comme non fiables – Chaque citation de source est revérifiée par des agents indépendants, empêchant un seul document erroné de contaminer la réponse.

Ces principes font écho à une tendance plus large vers des architectures de type « modèle hors du modèle », où un code déterministe gère l'orchestration, la validation et l'allocation des ressources au lieu du modèle de langage probabiliste.

Inconvénients potentiels et questions ouvertes

La force du pipeline — sa rigueur — apporte également des défis.

Un autre point de discorde est la dépendance aux citations textuelles. Toute la connaissance ne réside pas dans une formulation exacte ; certains enseignements n'émergent qu'après une synthèse de plusieurs documents.

À surveiller ensuite

Le Deep Research de Claude est encore en phase de recherche, mais son architecture laisse entrevoir un avenir où les grands modèles de langage seront intégrés dans des pipelines étroitement contrôlés plutôt que de les laisser s'auto-diriger. Les indicateurs clés à surveiller incluent :

  • Métriques d'efficacité des tokens – La base de référence de 6,57 M de tokens diminuera-t-elle à mesure que le dispositif gagnera en logique de tri sélectif ?
  • Tendances de latence – À quelle vitesse le système peut-il renvoyer un rapport complet lorsque trois agents de vérification interviennent dans la boucle ?

À retenir

Le Deep Research de Claude montre qu'un modèle de langage peut produire des réponses fiables et fondées sur des sources lorsqu'il est confiné à un pipeline discipliné à plusieurs étapes. La véritable percée ne réside pas dans la taille du modèle, mais dans le logiciel environnant qui force le modèle à prouver chaque affirmation, à classer les preuves avant de consommer de la puissance de calcul, et à traiter chaque extrait externe comme suspect jusqu'à ce que trois agents en conviennent autrement. Pour quiconque développe des outils pilotés par l'IA, la leçon est claire : laissez le modèle réfléchir, mais laissez le code décider de ce qu'il peut dire.