La deep research est un workflow de vérification

La deep research devient puissante quand elle se comporte moins comme un chatbot et davantage comme un système de vérification.

Cette distinction compte. Un chatbot répond à la question posée. Un système de vérification reconstruit la question, cartographie les preuves, remet en cause les hypothèses, vérifie l'état actuel des choses et refuse de traiter un paragraphe bien tourné comme une preuve.

La plupart des recherches assistées par IA ressemblent encore à la première version. Demandez à un modèle un panorama de marché, une analyse concurrentielle, un résumé technique ou une note stratégique, et il produira généralement quelque chose de plausible. Il trouvera les sources évidentes. Il résumera proprement. Il écrira avec assurance. Pour un travail à faibles enjeux, cela peut suffire.

Pour un travail à forts enjeux, la plausibilité est précisément le mode de défaillance.

Le workflow de deep research que j'utilise est conçu autour de ce problème. Sa valeur ne tient pas au fait qu'il produit des rapports plus longs. Ni au fait qu'il mobilise plus d'agents pour la seule beauté de la complexité. Le levier vient d'une boucle opératoire reproductible : découvrir le contexte, cartographier les affirmations, collecter les preuves, contester le brouillon, corriger l'artefact et valider l'ensemble du système avant de considérer le travail terminé.

Le changement essentiel est le suivant : le résultat n'est pas traité comme une note figée. Il est traité comme un graphe de preuves vivant.

La recherche ordinaire s'arrête trop tôt

La recherche à agent unique est rapide, et cette rapidité est utile. Mais elle a des faiblesses prévisibles.

Elle passe à côté du contexte système. Une nouvelle conversation ne connaît pas automatiquement l'arborescence des sources, les notes, les jeux de données, les critères d'acceptation ou la forme de l'artefact final. Elle part du prompt visible, pas de l'environnement de travail complet.

Elle accepte des affirmations périmées. Une source correcte hier peut être fausse aujourd'hui. Une note de QA peut décrire un problème déjà résolu. Un jeu de données généré peut conserver une ancienne formulation après la modification de l'artefact visible.

Elle mélange preuve et interprétation. Le modèle peut résumer une affirmation technique, une estimation de marché ou un document source d'une manière qui sonne juste tout en modifiant discrètement la portée de l'affirmation.

Elle s'arrête à la prose. Même lorsqu'elle repère un problème, le travail se termine souvent par un commentaire : « Cette citation semble obsolète » ou « Cette section devrait être révisée ». C'est utile, mais ce n'est pas de la vérification. Vérifier signifie que le document, les données, les citations, les notes et l'état de validation concordent tous après la correction.

Voilà pourquoi une recherche superficielle peut paraître aboutie tout en restant fragile. Le document final se lit bien, mais la chaîne d'affirmations qui le sous-tend n'a jamais été forcée de survivre à un examen.

La deep research est ma réponse à cette fragilité.

Le workflow

Le workflow comporte six phases. Elles sont simples, mais l'ordre compte.

1. Découverte du contexte

La première étape n'est pas l'écriture. C'est l'orientation.

Avant de chercher à l'extérieur, le workflow explore les fichiers locaux, les notes, les exports de sources, les jeux de données et tout artefact de QA existant. L'objectif est d'éviter le problème d'amnésie : repartir de zéro alors que l'espace de travail contient déjà du contexte pertinent.

Cette phase répond à des questions comme :

Quel contexte existe déjà ?
Quelles affirmations sont centrales pour le livrable ?
Quelles sources sont déjà rattachées ?
Quels résultats pourraient être périmés ?
Que signifie « terminé » pour cet artefact ?

Cette dernière question est facile à sauter. C'est aussi là que beaucoup de recherches assistées par IA échouent. Une note de recherche, un brief technique, un dashboard et une annexe n'ont pas les mêmes critères d'acceptation. Le workflow doit identifier la forme de l'artefact avant de pouvoir juger la qualité du contenu.

2. Cartographie des sources et des affirmations

Ensuite, le workflow cartographie l'artefact comme un système.

Dans une relecture classique, on lit la prose. Dans une relecture de vérification, on relie les affirmations aux preuves. Quelles déclarations dépendent de quels identifiants de source ? Quels graphiques dépendent de quels jeux de données ? Quelle annexe reprend une affirmation du résumé exécutif ? Quelles citations visibles sont générées à partir d'un export de sources ?

C'est ici que le livrable cesse d'être un document pour devenir un graphe :

Affirmations
Sources
Références de sources
Fichiers de données
Notes
Annexes
Entrées de sources
Scripts de validation

Une fois le graphe visible, la dérive devient plus facile à détecter. Une affirmation corrigée dans le document principal ne suffit pas si la même affirmation périmée survit dans une annexe, dans des données JSON, dans les notes de sources ou dans un export généré.

3. Recherche et vérification en parallèle

Ce n'est qu'après la cartographie du contexte et des affirmations que le workflow se déploie en éventail.

Différentes pistes de recherche peuvent travailler en parallèle : l'une vérifie la couverture des sources, une autre les affirmations techniques, une autre les chiffres et les hypothèses, une autre les métadonnées et l'alignement des citations. Le but n'est pas de mettre en scène un travail « multi-agents ». Le but est la séparation des responsabilités.

Le chercheur qui rassemble les sources ne devrait pas être le seul critique de l'interprétation. L'agent qui vérifie les identifiants de source ne devrait pas se laisser distraire par le fil narratif. La piste qui examine les affirmations techniques devrait pouvoir dire : « La prose est claire, mais l'affirmation est trop forte. »

Le parallélisme compte parce qu'il préserve la perspective. Il accélère aussi le travail, mais la rapidité n'est pas le bénéfice principal. Le bénéfice principal, c'est que chaque piste peut tenir un standard plus étroit et l'appliquer avec plus de rigueur.

4. QA adversariale

La quatrième phase est délibérément sceptique.

Le workflow traque les résultats périmés, la dérive des citations, les identifiants de preuve cassés, les ancres dupliquées, les liens internes morts, les incohérences dans les données générées et les conclusions surestimées. Il vérifie si d'anciennes notes de QA décrivent encore l'artefact actuel. Il vérifie si des ressources avec cache-busting sont réellement manquantes ou si elles semblent seulement manquantes parce que le validateur lit le nom de fichier de façon trop littérale. Il vérifie si l'export de sources utilise la clé attendue ou un identifiant stable différent.

Cela compte parce que les artefacts de recherche échouent de manière ennuyeuse.

Les erreurs dangereuses ne sont pas toujours de grosses hallucinations. Ce sont souvent de petits décalages :

Une affirmation chiffrée pointe vers le mauvais identifiant de source.
Une affirmation de statut cite une source voisine mais plus faible.
Un résumé technique promeut un détail secondaire au rang d'affirmation principale.
Une entrée de source a le bon sujet mais la mauvaise référence sous-jacente.
Un fichier de validation conserve un résultat déjà remplacé.
Un document et une annexe se contredisent désormais parce qu'un seul des deux a été corrigé.

Ces défauts sont faciles à manquer lors d'une simple lecture. Ce sont exactement ceux qu'un workflow de vérification est censé attraper.

5. Correction directe

Trouver un problème n'est pas la ligne d'arrivée.

Quand le workflow confirme une erreur, il corrige l'artefact directement. Cela peut signifier mettre à jour la prose visible, les données générées, les correspondances de sources, les exports de sources, les notes ou les résumés de validation. La correction doit atterrir là où vit l'affirmation, pas seulement là où le problème a été remarqué.

C'est la plus grande différence entre la deep research et la recherche ordinaire assistée par IA. Le workflow ne se contente pas d'une critique. Il veut que le livrable devienne plus vrai.

Le standard, c'est la correction guidée par la preuve, pas la réécriture spéculative. Si une affirmation n'est pas vérifiée, le workflow la restreint. Si une source est périmée, il la remplace ou la nuance. Si une subtilité technique ne peut pas être pleinement confirmée, il préserve l'incertitude plutôt que de transformer une estimation en fait.

6. Validation finale

La phase finale est mécanique et nécessaire.

Après les corrections, le workflow valide de nouveau le système : les références de sources se résolvent, le JSON se parse, les ressources locales existent, les liens internes fonctionnent, les identifiants dupliqués sont absents, les exports de sources s'alignent et les vérifications de formatage passent.

Cette phase n'a rien de glamour. C'est pourtant là que se gagne la confiance. Un artefact de recherche peut avoir une prose excellente et rester cassé sur le plan opérationnel. Des citations rompues, des fichiers générés périmés et des structures de données invalides ne sont pas des détails de présentation. Ce sont les preuves que l'artefact n'a pas réellement retrouvé un état cohérent.

La deep research ne se termine que lorsque l'artefact et sa couche de preuves concordent.

Le système que j'ai construit

Le système repose sur une hypothèse simple : la qualité d'une recherche dépend de l'intégrité de l'artefact entier, pas seulement du texte visible.

L'artefact peut être un brief en markdown, un rapport structuré, une page adossée à un jeu de données, une note avec annexes ou un livrable généré. Le format exact change. La boucle de contrôle, elle, ne change pas.

Une relecture superficielle lit le document de premier niveau, propose quelques ajustements de formulation, puis s'arrête.

Le système de deep research traite le livrable comme un ensemble de surfaces reliées entre elles :

Sections narratives
Correspondances de sources
Fichiers de données
Notes
Annexes
Exports générés
Artefacts de validation

Chaque surface est vérifiée par rapport aux autres. Si la narration dit une chose et les données une autre, le système signale le décalage. Si une citation pointe vers la mauvaise source, le système traite cela comme une défaillance d'affirmation, pas comme un détail cosmétique. Si un résultat généré conserve une formulation périmée, le système remonte l'affirmation jusqu'à la couche source au lieu de se contenter d'éditer le paragraphe.

C'est la partie qui me tient le plus à cœur. Le workflow ne sépare pas l'écriture de la vérification. Il rend l'écriture redevable à la couche de preuves.

Le système a trois missions :

Garder le graphe de sources visible.
Garder les affirmations rattachées à la bonne preuve.
Garder l'artefact final cohérent en interne après les corrections.

Cela rend le workflow utile bien au-delà d'un seul domaine. Il peut traiter l'étude de marché, l'analyse technique, la stratégie produit, la revue concurrentielle et l'aide à la décision interne, parce que le problème de fond est le même : les affirmations s'éloignent des preuves à moins que le système ne les ramène sans cesse.

C'est toute la différence entre « j'ai relu le document » et « l'artefact est désormais plus fiable ».

Pourquoi cela produit des effets cumulés

Le workflow prend de la valeur avec le temps, car chaque exécution laisse derrière elle un meilleur contexte.

Une conversation ordinaire produit une réponse. Un workflow de vérification produit une réponse, mais aussi des correspondances de sources, des artefacts corrigés, des notes de validation et une connaissance réutilisable des endroits où l'artefact était fragile. L'exécution suivante démarre à partir du contexte système au lieu de repartir à froid.

C'est l'effet cumulé qui m'intéresse. Le système de recherche devient meilleur pour attraper les types d'erreurs propres à la recherche structurée. Il apprend que les données générées peuvent diverger de la prose visible. Il apprend que d'anciens fichiers de QA peuvent être périmés. Il apprend que les identifiants de source comptent autant que les titres de source. Il apprend que les résumés techniques exigent une discipline sur la portée des affirmations.

Cela ne rend pas le workflow autonome au sens imprudent du terme. Cela le rend plus inspectable. L'humain reste maître du jugement. Le workflow rend simplement la piste des preuves plus facile à auditer.

Cela change aussi le rôle de l'opérateur. Le travail à plus fort levier n'est pas de demander : « Peux-tu faire cette recherche ? » C'est de définir ce qui compte comme preuve, quelles surfaces doivent concorder, quels risques méritent une revue adversariale et quelle validation doit passer avant qu'on fasse confiance au résultat.

Autrement dit, l'opérateur ne se contente pas de prompter. L'opérateur conçoit le système de contrôle de la recherche.

Ce qui peut mal tourner

La deep research n'a rien de magique. Elle peut échouer si la discipline opératoire s'effondre.

Elle peut trop se fier à ses propres notes intermédiaires. Une checklist de QA est utile, mais elle peut être périmée. L'artefact actuel doit être vérifié directement.

Elle peut surajuster à la structure générée. Un validateur peut signaler une ressource manquante parce qu'il n'arrive pas à retirer les query strings des chemins locaux. Une vérification de CSV peut supposer que la clé stable est id alors que l'export utilise en réalité evidence_id.

Elle peut surestimer des affirmations incertaines. Le dimensionnement de marché, le périmètre technique, le positionnement concurrentiel et l'interprétation des sources comportent souvent une incertitude qui devrait survivre jusque dans la prose finale.

Elle peut ne corriger que la couche visible. C'est la défaillance la plus fréquente. Le document se lit correctement, mais les données, les notes ou l'export de sources portent encore l'ancienne affirmation.

La parade est ennuyeuse et stricte : cartographier le système, vérifier autant que possible par rapport à des sources primaires ou durables, corriger chaque surface dépendante et valider après les modifications.

Le modèle mental réutilisable

La version la plus simple du workflow tient en quatre verbes :

Cartographier. Vérifier. Corriger. Valider.

Cartographier les affirmations et les surfaces où elles apparaissent.

Vérifier les affirmations par rapport au matériau source, pas par rapport à l'assurance de la prose.

Corriger l'artefact réel, y compris les données générées et les couches de citation.

Valider que le livrable final est cohérent en interne.

Voilà ce qui distingue la deep research du simple résumé par IA. Elle n'optimise pas pour un premier jet persuasif. Elle optimise pour un livrable capable de survivre au contact de ses propres preuves.

Pour les opérateurs techniques, les founders, les stratèges produit et les power users de l'IA, c'est la partie qui vaut la peine d'être copiée. Ne construisez pas un workflow de recherche qui se contente d'écrire davantage. Construisez-en un qui rend les affirmations redevables.

L'avenir de la recherche assistée par IA n'est pas la réponse la plus longue. C'est la réponse dont le graphe de preuves tient encore debout après l'examen.