Toutefois, bien des gens ont pu utiliser la recherche approfondie à titre individuel — pour chercher et synthétiser de l’information en ligne —, mais peu en ont bénéficié dans un contexte d’entreprise. Ce n’est pas parce qu’elle serait inutile — bien au contraire —, mais plutôt en raison de préoccupations générales concernant la fiabilité, la disparité des sources de données ou la capacité d’un modèle à traiter un vaste contexte, notamment un très grand nombre de types de fichiers variés.
Notre expérience de la création d’outils de recherche approfondie de calibre entreprise au cours des 12 derniers mois montre qu’une ingénierie réfléchie permet de mieux en mieux d’atténuer ces préoccupations. Dans cet article, nous abordons les principaux obstacles aux applications efficaces de recherche approfondie d’entreprise, la façon dont nous les surmonterions et l’évolution que nous prévoyons en 2026.
Le plafond d’exécution a bondi de façon spectaculaire. L’arrivée de gpt-5 en août 2025 a marqué un tournant pour l’IA d’entreprise. Dans nos systèmes de production, dont une plateforme de découverte de cibles thérapeutiques destinée à l’une des plus grandes sociétés pharmaceutiques au monde, le taux d’hallucination de sources est passé de 3 à 4 % à pratiquement zéro. Puis, en décembre, gpt-5.2 a encore accru la longueur de contexte effective. Résultat concret : nous pouvons maintenant passer de centaines à des milliers de sources par cycle de recherche, sans sacrifier la fiabilité. Le goulot d’étranglement est revenu là où il doit être : vos données, vos évaluations et la conception de votre programme.
Stratégie de données : l’accessibilité l’emporte sur l’unification. Il est compréhensible de considérer l’IA d’entreprise comme un problème d’intégration de données, mais cette approche est souvent contre-productive. L’unification complète est lente et politique, et elle impose des choix prématurés avant même de savoir quelles questions comptent réellement. En 2026, l’approche pragmatique consiste à privilégier une connectivité éparse. Rendez les données accessibles grâce à des points d’ancrage à signal fort — spécifications, politiques, UGS et clauses contractuelles — plutôt que d’attendre des années pour tout unifier. Les modèles de pointe peuvent maintenant effectuer des « jointures souples » entre les systèmes au moment de l’inférence, reliant des termes connexes sans correspondances formelles. Vous conservez votre rapidité de déploiement et la souplesse nécessaire pour ajouter des sources plus tard.
La navigation évite l’errance. Les données d’entreprise ne sont pas le Web. Elles sont éparses, remplies de conventions locales et ne comptent souvent qu’une seule bonne source pour un fait donné. Sans orientation, les modèles ont tendance à multiplier indéfiniment les requêtes pour trouver une source de plus, au détriment de la latence et de la patience des utilisateurs. Une couche sémantique légère — tables de hachage, recherches d’entités et graphes de relations simples — offre au système des moyens rapides et peu coûteux d’atteindre efficacement le bon contexte. Voyez cela comme les conseils d’un collègue chevronné à une nouvelle recrue : « Ajoute ces sites à tes favoris; parle à Ross si tu as des problèmes avec AWS. » Nul besoin de compliquer les choses. Il suffit d’aider le système à trouver rapidement ce dont il a besoin.
Mécanique (à chaque requête) : qualité des citations, bonne utilisation des outils, latence et coût. Ce sont vos garde-fous : banals, mais essentiels.
Analytique (périodique) : le système choisit-il les bons outils et axes de recherche, sélectionne-t-il des sources fiables et sait-il quand s’arrêter? Le rendement est généralement noté par un LLM agissant comme juge à partir d’exemples étiquetés.
Utilisateur (en continu) : taux d’achèvement des tâches, commentaires qualitatifs des utilisateurs avancés et données d’utilisation. Le test ultime. Avons-nous créé quelque chose que les gens trouvent utile?
Le RCI vient des problèmes difficiles, pas des problèmes sans risque. Après la publication de rapports affirmant que la plupart des projets d’IA d’entreprise n’atteignent pas leur RCI, la tolérance envers les démonstrations impressionnantes qui ne sont jamais déployées s’est évaporée. Les dirigeants veulent des preuves, et rapidement. Paradoxalement, cette pression peut pousser les équipes à faire les mauvais choix. Il est tentant de commencer par des tâches à faible risque, car elles sont faciles à déployer et peu susceptibles de froisser qui que ce soit. Mais ces cas d’utilisation ont rarement un effet suffisant pour justifier la poursuite des investissements. Les systèmes de recherche approfondie d’entreprise sont bien placés pour démontrer leur valeur, car ils ciblent des tâches déjà coûteuses : des flux de travail complexes et critiques dont le statu quo a un coût visible. Les meilleurs cas d’utilisation que nous avons vus concernent notamment la production de demandes de propositions et de soumissions, l’analyse du paysage scientifique et la recherche en investissement — des domaines où l’incidence se mesure par le taux de réussite, l’accélération des essais et la rapidité de conviction, pas seulement par les heures économisées.
Le virage de l’expérience utilisateur : de la conversation à la délégation, et des réponses aux livrables. Nous pensons qu’il s’agit de l’un des virages de l’expérience utilisateur qui définiront 2026. Deux éléments ressortent des solutions récemment les mieux adoptées. À mesure que la fiabilité de ces systèmes augmente, les utilisateurs les traitent moins comme des robots conversationnels à interroger et davantage comme des analystes auxquels déléguer du travail. Deux facteurs rendent ce changement possible : permettre aux équipes d’adapter les modèles de documents et les critères d’arrêt à leurs flux de travail, puis d’exporter directement dans le format requis — note, présentation, dossier, etc. — plutôt que de leur demander de produire un livrable final à partir d’une conversation. Lorsque ces deux éléments sont réunis, le système cesse d’être un outil de référence et devient un véritable mode d’exécution du travail.
L’an dernier, nous avons expliqué comment offrir la recherche approfondie aux entreprises. Nous avons repris le paradigme de recherche approfondie axé sur le Web, initialement popularisé par OpenAI, et l’avons étendu aux sources de données exclusives des entreprises sans perdre la provenance ni le contrôle. Nous avons également souligné que les systèmes de recherche approfondie ne constituent pas une rupture avec les systèmes RAG plus classiques, mais plutôt une évolution de ceux-ci.
À l’approche de 2026, ce n’est pas tant l’idée de la recherche approfondie qui a changé que le plafond d’exécution possible.
Lorsque nous avons commencé à créer ces systèmes au début de 2025, les modèles de pointe comprenaient o1, gpt-4o et claude-3.5-sonnet — que de chemin parcouru en seulement 12 mois —, puis des modèles comme o3 et gemini-2.5-pro ont permis de grandes avancées au cours des premiers mois de l’année. Ils étaient excellents pour leur époque et permettaient assurément de créer des applications robustes de recherche approfondie, jusqu’à un certain point. Cette limite se situait généralement dans les quelques centaines de sources. Au-delà, il fallait élaguer très vigoureusement le contexte, sous peine d’obtenir une réponse appauvrie, une dégradation du respect des consignes ou de véritables hallucinations.
Si vous avez créé de tels systèmes, vous reconnaîtrez certains de ces modes de défaillance.
Voici un exemple concret : au milieu de 2025, nous avons commencé à créer une solution de recherche approfondie d’entreprise avec l’une des plus grandes sociétés pharmaceutiques au monde. Ce système accélère la découverte de cibles thérapeutiques, un processus où les chercheurs repèrent des gènes, des hormones ou d’autres éléments du corps humain pouvant être ciblés pour traiter une affection. À l’époque, le modèle le plus puissant disponible était o3. Malgré son solide rendement, de 3 à 4 % des réponses produites par ce modèle contenaient des sources qui ne lui avaient pas été fournies par des appels d’outils aux sources de données exclusives du client. Nous avons atténué ce problème grâce à des vérifications de citations après coup, qui signalaient les parties des réponses non étayées par le contexte fourni. Cette méthode a permis de renforcer la confiance des parties prenantes envers l’outil pendant la phase initiale de validation de principe du projet et nous a aidés à progresser rapidement. Nous avons toutefois continué à réduire ces erreurs, en tentant d’atténuer les limites des modèles tout en répondant aux demandes des parties prenantes qui souhaitaient ajouter d’autres sources au système.
L’arrivée de gpt-5 en août a marqué un tournant majeur pour la création de solutions de recherche approfondie de pointe — et, plus généralement, de solutions agentiques. Lorsque nous avons remplacé o3 par gpt-5, nos évaluations ont montré que le taux d’hallucination de sources est immédiatement tombé à 0 %.
Précisons cette mesure : elle indique strictement si le modèle cite un identifiant de document ou une URL qui ne figurait pas dans le contexte récupéré. À l’époque de o3 — et avant —, les modèles inventaient parfois des noms de fichiers ou des articles plausibles pour combler les lacunes de leurs connaissances. gpt-5 nous a permis d’éliminer pratiquement cette anomalie précise.
Il faut distinguer ce problème des erreurs de fidélité — citer le bon document, mais mal interpréter le texte —, qui demeurent un défi que nous gérons à l’aide des vérifications après coup mentionnées précédemment.
Cette avancée a débloqué d’immenses possibilités. Nous avons alors commencé à tester le système pour déterminer jusqu’où nous pouvions le pousser avec cette nouvelle génération de modèles. Nous avons constaté que nous pouvions multiplier approximativement par dix le nombre de sources examinées au cours d’un cycle de recherche approfondie — pour atteindre environ 3 000 à 5 000 sources. La limite ultime n’était pas une dégradation du respect des consignes, mais le rendement sur les longs contextes : la longueur de contexte effective des modèles est souvent bien inférieure à celle annoncée, surtout avec des données pharmaceutiques denses, par exemple.
La sortie de gpt-5.2 à la mi-décembre a partiellement atténué cette contrainte. Nos bancs d’essai internes sur les longs contextes ont révélé une nette amélioration du rendement effectif, ce qui nous a permis de pousser encore plus loin nos systèmes de recherche approfondie de pointe. Cette amélioration nous a permis d’augmenter le nombre de tokens transmis directement au modèle qui produit le résultat destiné à l’utilisateur, et donc de fournir une réponse plus riche. Nous souhaitons néanmoins que la longueur de contexte effective des modèles de pointe continue d’augmenter en 2026.
Compte tenu de ces avancées des capacités brutes des modèles, les goulots d’étranglement qui freinent la création de systèmes de recherche approfondie performants sont, à bien des égards, revenus là où ils auraient toujours dû se trouver : vos données, vos évaluations et la façon dont vous structurez votre programme de recherche approfondie dans l’entreprise. Chacune de ces étapes exige des décisions pragmatiques sur les facteurs qui produisent de réels progrès dans un projet de recherche approfondie.
La suite de cet article présente notre façon d’aborder ces décisions.
Il peut être tentant de traiter les projets de recherche d’entreprise comme un problème d’intégration de données. Unifiez les sources, normalisez le schéma et laissez les modèles les exploiter librement.
Soyons clairs : c’est parfois exactement la bonne approche. Si vous travaillez dans un domaine où les entités principales sont stables, les requêtes sont répétitives et l’objectif ultime est d’industrialiser le flux de travail, l’unification peut procurer de réels avantages. Parmi les cas classiques figurent les jointures entre les données sur les clients et les revenus, les données sur les prix du marché et tout scénario exigeant des rapports fiables qui couvrent plusieurs systèmes.
Toutefois, dans la pratique, les leaders novateurs d’aujourd’hui recherchent autre chose dans les systèmes de recherche approfondie d’entreprise.
Alors que le RCI des dépenses en IA suscite une attention croissante, les décideurs cherchent surtout à démontrer rapidement la valeur dans la réalité complexe du fonctionnement de l’entreprise. Or, l’unification complète des sources de données est l’un des moyens les plus lents d’obtenir cette première preuve. C’est lourd. Cela devient politique. Et cela vous oblige souvent à choisir une direction avant de savoir quelles questions comptent réellement.
Nous croyons donc qu’en 2026, le point de départ pragmatique pour créer des systèmes de recherche approfondie de pointe consiste généralement à rendre vos données accessibles avant de les embellir.
Si vous prévoyez vraisemblablement ajouter des sources au fil du temps — comme la plupart des entreprises —, la connectivité éparse est sous-estimée. Vous pouvez exposer des dizaines de sources derrière une interface de récupération uniforme. Le système pourra tout de même fonctionner et, surtout, vous conserverez votre capacité à livrer rapidement. Lorsque vient le temps d’ajouter des sources, vous n’avez pas à tout bouleverser. Vous pouvez simplement brancher un nouveau connecteur, expliquer au système central ce qu’il est et comment l’utiliser, puis laisser les modèles prendre le relais. Cette méthode fonctionne parce que les modèles de pointe actuels peuvent effectuer des jointures souples entre au moins deux sources de données au moment de l’inférence, reliant « ID client » dans un système à « Référence client » dans un autre, sans correspondance formelle. Nous ne sommes pas la seule équipe à penser ainsi. Nous ne sommes pas la seule équipe à penser ainsi : l’agent de données interne d’OpenAI permet aux modèles de raisonner sur 70 000 ensembles de données hétérogènes en rendant le contexte et les connexions accessibles au moment de la requête, plutôt que d’imposer une unification complète en amont.
Il convient de préciser que le caractère épars n’implique pas nécessairement un manque de profondeur.
L’intégration éparse fonctionne mieux lorsque les connexions établies sont pertinentes et exprimées de façon à être facilement exploitables par le système. Une bonne façon de l’envisager consiste à traiter certains renseignements comme des points d’ancrage : spécifications, politiques, définitions de produits, UGS, clauses contractuelles, etc. Il n’est pas nécessaire d’unifier chaque ensemble de données pour rendre ces points d’ancrage puissants; il suffit d’un identifiant stable et de quelques liens à signal fort.
Imaginez, par exemple, qu’un modèle — ou un utilisateur — recherche une spécification. Dans un système naïf, l’interaction s’arrête là. Vous récupérez la spécification, la résumez et, peut-être, la citez. Toutefois, lorsque nous concevons des structures de données utiles, nous voulons faire de cette recherche le point de départ d’une expansion contrôlée. Nous pourrions, par exemple, relier facultativement le dossier de cette spécification à des livrables historiques pertinents. Le terme « pertinent » peut avoir plusieurs sens, mais il dépend généralement de la tâche exécutée par le système. Il pourrait donc inclure les demandes de propositions mentionnant la spécification, les réponses antérieures ayant remporté des soumissions fondées sur celle-ci, les révisions où le service juridique s’y est opposé, etc. Cette approche peut améliorer considérablement la qualité et la latence des réponses, en présentant rapidement au système de recherche approfondie les observations les plus importantes au moment de la requête.
Cela soulève la question suivante : une fois que vous disposez d’un univers de sources de données reliées de façon éparse par quelques liens à signal fort, comment empêcher le système de recherche approfondie d’errer comme un enfant dans un magasin de bonbons et l’amener plutôt à naviguer comme un analyste chevronné?
Les sources de données d’entreprise ne se comportent pas comme le Web. Elles sont éparses, remplies de conventions locales et ne comptent souvent qu’une seule « bonne » source pour un fait donné — encore faut-il la trouver. De plus, les modèles actuels ont tendance à toujours maximiser le rappel des recherches, multipliant souvent les requêtes pour trouver une seule source de plus, au détriment de la latence et de la patience des utilisateurs. Des invites soigneusement conçues peuvent atténuer ce problème dans une certaine mesure.
La solution la plus efficace est un outil léger qui aide le modèle à s’orienter dans le paysage désordonné des données d’entreprise. Certaines équipes parlent d’une ontologie. D’autres parlent d’une couche sémantique, d’un service de recherche, d’un graphe ou d’un référentiel de concepts. Le terme importe peu.
Ce qui compte, c’est d’offrir au système des moyens rapides et peu coûteux de passer efficacement d’un élément de contexte pertinent à l’autre, plutôt que d’errer pendant ce qui semble être une éternité.
Une métaphore simple : vous venez d’arriver dans une nouvelle entreprise ou un nouveau projet, et vos collègues vous disent : « Tu dois ajouter ces sites à tes favoris, tu les utiliseras tout le temps » ou « si tu as un problème avec AWS, parle à Ross; il te donnera l’information nécessaire », et ainsi de suite. De même, nous cherchons simplement à aider le système de recherche approfondie à trouver rapidement ce dont il a besoin.
En pratique, ce système n’a pas besoin d’être complexe ni tenu à jour manuellement. Les meilleures mises en œuvre que nous avons trouvées sont soit produites par des LLM pendant le pipeline d’ingestion — les entités extraites alimentent automatiquement le graphe —, soit de simples passerelles vers des systèmes de référence existants, comme une recherche dans l’API Salesforce. Voici quelques exemples courants :
Recherches dans une table de hachage — par exemple, saisir le nom d’un produit et obtenir sa description
Recherche simple de relations « courantes » — par exemple, ce gène est le plus souvent associé à ces maladies dans notre graphe des relations causales entre gènes
Modèles de reconnaissance d’entités nommées — surtout utiles dans les domaines où la désambiguïsation des entités est complexe, comme le secteur pharmaceutique
Pour les relations de données les plus complexes, les graphes RDF légers peuvent constituer la solution d’ontologie la plus extensible
… et plus encore
Une fois cette structure en place, le système peut parcourir efficacement vos sources de données. La prochaine question est simple : comment savoir s’il fait systématiquement ce qu’il faut en situation réelle?
Maintenant que vos données sont accessibles et que votre couche de navigation fournit la carte, votre système est en mesure d’effectuer le travail. Mais dans un contexte d’entreprise, cette capacité ne vaut rien sans fiabilité.
C’est là que se trouve le plus grand cimetière de projets d’IA. De nombreuses équipes sont tombées dans le piège des évaluations « au feeling ». Elles lançaient une requête, lisaient le résultat, hochaient la tête avec satisfaction, puis le déployaient. Cette approche ne fonctionne pas lorsqu’on crée un système de recherche approfondie susceptible de parcourir de façon autonome 5 000 documents pour formuler une recommandation sur une décision de chaîne d’approvisionnement valant plusieurs millions de dollars.
Le changement important est que vous n’évaluez plus un modèle, mais un système. L’interprétation des questions, la planification, les appels d’outils, l’interprétation, l’élagage du contexte, le reclassement et même des détails apparemment banals des connecteurs, comme les horodatages, influencent tous l’expérience utilisateur.
Des évaluations structurées et reproductibles nous aident à résoudre ces problèmes.
Lors de leur conception, nous pouvons généralement répartir les évaluations en trois catégories, des plus mécaniques aux plus subjectives.
C’est la partie qui ressemble le plus aux tests unitaires et où les équipes peuvent souvent progresser le plus rapidement au départ. Ces évaluations sont aussi généralement les plus stables au fil du temps : une fois configurées, elles peuvent rester avantageuses pendant toute la durée du projet.
Les « évaluations mécaniques » sont généralement des vérifications exécutables à chaque requête, sans intervention humaine. Elles nous aident à vérifier que le système se comporte de façon prévisible et sûre sous des charges d’utilisation réelles.
En voici quelques exemples :
Qualité des citations : toutes les citations renvoient-elles à des passages réellement récupérés? Certaines affirmations sont-elles dépourvues de citation? Certaines affirmations ne sont-elles pas étayées par les sources? Les citations sont-elles trop générales, par exemple lorsqu’un document entier est cité pour une seule affirmation?
Bonne utilisation des outils : le système a-t-il utilisé tous les outils qu’il prétend avoir utilisés? A-t-il correctement utilisé les outils de navigation? A-t-il mal formaté certaines requêtes d’outil? A-t-il réessayé de façon judicieuse lorsque des erreurs se sont produites?
Budgets de latence et de coûts : a-t-il respecté le délai cible avant le premier token? A-t-il dépassé le nombre prévu d’appels d’outils ou le budget? A-t-il consommé beaucoup de temps et de puissance de calcul pour un gain marginal?
Ces vérifications semblent banales, mais ce sont précisément les tests qui empêchent un système d’entreprise de se dégrader.
Dans notre projet concret de recherche approfondie pour la découverte de cibles thérapeutiques, nous avons utilisé deux niveaux de vérification des citations à chaque requête. D’abord, lors de la production d’une réponse, nous demandons au modèle de fournir fréquemment des citations dans le texte. La capacité des LLM à le faire de manière fiable est elle aussi relativement récente, puisqu’elle est apparue au premier semestre de 2025. Quiconque a tenté auparavant de le faire sur un volume important de données comprend la difficulté que cela représentait. Nous pouvons ainsi effectuer quelques vérifications simples par expression régulière pour déterminer, par exemple, si un lien d’article absent des sources fournies est mentionné.
Le deuxième niveau de vérification est effectué après la diffusion en continu de la réponse. La réponse est d’abord divisée en blocs, puis chaque bloc est évalué : le système cherche dans les données récupérées des sources qui étayent les affirmations qu’il contient. Si aucune preuve ne les étaye, le système signale une hallucination potentielle.
Si les évaluations mécaniques sont vos tests unitaires, les évaluations analytiques sont votre revue de code.
Nous cherchons ici à comprendre si le système accomplit bien son travail. Nous cherchons généralement à savoir s’il utilise les bons outils, suit les bons axes de recherche, choisit les sources les plus fiables et sait quand s’arrêter, entre autres.
En pratique, ces évaluations prennent généralement la forme d’une série de paires question-réponse pour lesquelles, par exemple, l’ordre judicieux des appels d’outils est connu, ou encore la bonne décision à prendre à partir des recherches trouvées par le premier outil. Soulignons que ces paires n’ont pas à correspondre exactement aux entrées et sorties du système complet de recherche approfondie : ces méthodes peuvent aussi servir à tester des sous-processus. À l’aide de ces étiquettes, produites par une personne ou par un puissant modèle d’étiquetage — puissance toute relative ici —, nous pouvons utiliser un LLM agissant comme juge pour noter les cycles de recherche et évaluer leur rendement. En suivant ces notes au fil du temps, nous pouvons déterminer si nos changements améliorent le système dans la direction voulue ou s’ils ont causé une régression du rendement.
Comme ces cycles coûtent davantage en argent et en temps, ils devraient généralement être exécutés périodiquement, selon un calendrier défini ou avant les mises à jour de version.
Il existe aussi un avantage indirect intéressant : ces évaluations analytiques peuvent directement guider l’amélioration des connexions éparses évoquées précédemment. Si le modèle effectue à plusieurs reprises le même rapprochement de grande qualité — par exemple, « spécification → exemples de demandes de propositions historiquement pertinents » — même si les humains ne relient pas explicitement ces livrables aujourd’hui, c’est une information utile. Vous pouvez transformer ce rapprochement en lien ou en raccourci de premier ordre, réduisant ainsi la latence et améliorant la cohérence des prochains cycles.
C’est également ainsi que vous repérez l’une des tendances les plus coûteuses des systèmes de recherche approfondie : maximiser le rappel par défaut. Un modèle peut toujours trouver une source de plus. La question est de savoir s’il devrait le faire. Nous pouvons ajuster le modèle pour renforcer un comportement d’arrêt judicieux : le système reconnaît qu’une récupération supplémentaire est peu susceptible de changer la conclusion et choisit de fournir une réponse bien étayée qui répond à la question de l’utilisateur.
Les évaluations mécaniques vous indiquent que le système est sûr. Les évaluations analytiques vous indiquent qu’il est compétent. Les évaluations par les utilisateurs vous indiquent s’il est réellement utile.
C’est un autre domaine où de nombreuses équipes trébuchent. Elles créent une solution techniquement impressionnante que personne ne souhaite utiliser une deuxième fois. Dans un contexte d’entreprise, c’est la différence entre un déploiement réussi et un projet de recherche coûteux.
Les évaluations par les utilisateurs visent fondamentalement à déterminer si le système résout le bon problème de la bonne façon. Il faut aller au-delà de « a-t-il trouvé la bonne réponse? » et demander : « m’a-t-il fourni quelque chose d’exploitable? »
En pratique, les évaluations par les utilisateurs prennent généralement quelques formes :
Études sur l’achèvement des tâches : le système permet-il réellement aux utilisateurs d’accomplir leur travail plus rapidement ou plus efficacement? Il ne s’agit pas de savoir si le modèle pourrait répondre à une question, mais si un véritable utilisateur a obtenu ce dont il avait besoin dans son flux de travail réel.
Boucles de rétroaction qualitative : conversations structurées et régulières avec les utilisateurs avancés. Quelles requêtes exécutent-ils à plusieurs reprises? À quel moment perdent-ils confiance? Quand abandonnent-ils pour revenir à l’ancienne méthode? Ces séances révèlent souvent des modes de défaillance absents de vos ensembles de tests, car les utilisateurs posent leurs questions d’une façon que vous n’aviez pas prévue ou appliquent implicitement des normes de qualité dont vous ignoriez l’existence.
Données d’utilisation : quelles requêtes sont relancées? Quelles réponses sont copiées et utilisées ailleurs? À quels endroits les utilisateurs cliquent-ils sur le pouce vers le bas? Une baisse d’utilisation n’est pas toujours un échec — les utilisateurs obtiennent parfois leur réponse et passent à autre chose —, mais les tendances indiquant quand et comment ils abandonnent leurs requêtes en disent long sur les attentes auxquelles le système ne répond pas.
Ensemble, ces méthodes permettent de mesurer l’utilité sans deviner et de repérer les problèmes avant qu’ils commencent à miner la confiance des utilisateurs.
Toutefois, même un système qui obtient une note parfaite en exactitude mécanique et ravit ses premiers utilisateurs peut échouer au test ultime : augmenter le chiffre d’affaires de l’entreprise. La fiabilité et la satisfaction des utilisateurs ne sont que des conditions préalables. Pour franchir le fossé entre un projet pilote réussi et un actif d’entreprise transformateur, vous devez regarder au-delà du fonctionnement du système et vous concentrer sur son domaine d’application.
Nous avons expliqué comment mettre vos données au service de votre système, puis votre système au service de vos utilisateurs. Nous devons maintenant voir comment mettre ce système au service de votre entreprise.
Les dirigeants d’entreprise accordent récemment beaucoup d’attention à cet enjeu, et avec raison. Après la publication de rapports comme l’affirmation du MIT selon laquelle 95 % des projets d’IA d’entreprise n’atteignent pas leur RCI, la tolérance envers les démonstrations impressionnantes qui ne sont jamais déployées s’est évaporée. Les modèles sont prêts. Les architectures ont fait leurs preuves. La question est maintenant la suivante : pouvez-vous réellement déployer cette solution de façon à créer de la valeur pour votre entreprise?
La bonne nouvelle, c’est que les systèmes de recherche approfondie de pointe fondés sur les principes précédents sont bien placés pour répondre à cette exigence. Ils ne cherchent pas à tout automatiser ni à remplacer des fonctions professionnelles entières. Ils cherchent à accroître considérablement l’efficacité de vos meilleurs employés dans le travail à forte valeur qu’ils accomplissent déjà.
Mais pour passer d’un système « techniquement fonctionnel » à un système qui « génère un RCI », quelques catalyseurs supplémentaires sont nécessaires : des choix organisationnels, d’expérience utilisateur et de mesure qui détermineront s’il devient un outil quotidien ou un onglet oublié.
D’après notre expérience, il y en a deux.
Il est souvent tentant de commencer par des tâches internes à faible risque, comme « résumer cette réunion ». Malgré leur sûreté, ces cas d’utilisation démontrent rarement une valeur suffisante pour justifier leur coût.
Les systèmes de recherche approfondie réussissent surtout lorsqu’ils ciblent des tâches vastes et difficiles : des problèmes coûteux pour lesquels une amélioration de la qualité ou de la rapidité produit une hausse démontrable des revenus ou un avantage stratégique.
Le RCI est maximal lorsque les entreprises ciblent des points d’entrée tels que les suivants :
Production de soumissions complexes et de réponses aux demandes de propositions : les systèmes de recherche approfondie peuvent extraire automatiquement les réussites historiques les plus similaires — ainsi que les échecs —, repérer les quelques clauses qui entraînent toujours des révisions, trouver les meilleures preuves pour une exigence donnée et plus encore, puis transformer le tout en un positionnement solide et cohérent pour l’appel d’offres. Ici, la mesure n’est pas le temps économisé, mais le taux de réussite, la préservation des marges et la réduction des surprises juridiques ou commerciales tardives.
Analyse du paysage scientifique : dans les organisations axées sur la R&D — produits pharmaceutiques, biotechnologie ou semi-conducteurs —, le point d’entrée consiste à condenser des semaines de publications et de connaissances internes en une piste de recherche exploitable. Un système de recherche approfondie peut consulter des milliers d’articles, de brevets, de rapports internes, de notes de laboratoire et d’examens de programmes antérieurs afin de cartographier les connaissances établies et contestées et de produire un portrait étayé par des preuves. Il peut ainsi accélérer les cycles d’itération, réduire les pistes sans issue et, surtout, raccourcir le délai avant le premier essai chez l’humain.
Analyse des marchés : pour les banques et les fonds spéculatifs, la valeur consiste à transformer des recherches internes fragmentées — notes, modèles, transcriptions et commentaires de courtiers — et des signaux externes — documents réglementaires, résultats, données macroéconomiques et actualités — en soutien transactionnel apte à éclairer les décisions. Un système de recherche approfondie peut créer et actualiser en continu une vue d’une entreprise, d’un thème ou d’une question macroéconomique, faire ressortir les principaux changements depuis la semaine précédente, réconcilier les sources contradictoires et produire une note d’investissement ou un dossier de transaction avec une provenance complète.
Le point commun est qu’il ne s’agit pas de conversations. Ce sont des flux de travail complexes qui exigent habituellement des consultants externes coûteux ou des semaines de travail de cadres supérieurs. Lorsqu’un système de recherche approfondie s’attaque à ces problèmes, sa valeur est indéniable.
Il s’agit de l’un des virages de l’expérience utilisateur qui définiront 2026.
Si votre système de recherche approfondie est simplement un robot conversationnel que les utilisateurs interrogent pour trouver de l’information, son utilisation peut rapidement devenir sporadique. Il demeure un outil de référence, et les utilisateurs doivent ultimement compiler eux-mêmes ses résultats pour produire le livrable souhaité. En revanche, s’il ressemble à un analyste toujours disponible auquel on peut confier du travail, il peut transformer complètement le modèle opérationnel de l’équipe.
Nous observons un passage de la « conversation » — de courts échanges — à la délégation : définir une portée, un modèle de document et un objectif, puis laisser le système travailler.
Trois changements précis rendent cela possible :
Des résultats sous forme de livrables : le travail à forte valeur se trouve rarement dans une fenêtre de clavardage; il prend plutôt la forme de documents, de notes et de présentations. Les systèmes modernes de recherche approfondie devraient sauter l’étape de la conversation et produire directement le livrable final. Lorsqu’un utilisateur peut demander une « note d’investissement de trois pages dans notre format d’entreprise » et recevoir un fichier téléchargeable plutôt qu’un flux de texte, le délai de rentabilisation chute radicalement. Cette fonction s’étend aussi souvent aux productions planifiées : les utilisateurs peuvent demander la création automatique de courriels ou de rapports présentant de nouvelles observations et leur distribution aux parties concernées à mesure que de nouvelles données apparaissent.
Optimisation locale grâce à des modèles de documents personnalisés : les modèles sont maintenant assez robustes pour permettre aux unités commerciales, voire aux utilisateurs individuels, d’adapter leurs propres invites et comportements sans compromettre le système. Un rapport sur les risques n’a pas la même apparence à Londres qu’à New York. En permettant aux équipes de téléverser ou de concevoir leurs propres modèles structurels et de définir leurs critères d’arrêt — par exemple, « toujours consulter ces trois bases de données internes » — ou leur format de sortie, vous augmentez considérablement la valeur du système pour les utilisateurs et leur donnez envie de l’utiliser davantage.
La confiance comme interface : lorsqu’un utilisateur délègue une tâche dont l’exécution prend plus de 20 minutes, la confiance devient une priorité. Vous ne pouvez pas présenter une boîte noire. L’interface doit révéler le raisonnement et les choix du système, notamment en montrant à l’utilisateur les outils employés et en produisant des citations. Selon nous, la meilleure expérience utilisateur pour ces systèmes présente par défaut des observations générales sur la progression de la recherche et permet à l’utilisateur d’approfondir le tout en développant un volet latéral ou un élément similaire.
Nous envisageons un avenir où chaque entreprise de premier plan dispose d’un système de recherche approfondie adapté à ses flux de travail les plus critiques. Il prendra la forme d’une série d’analystes toujours disponibles, capables de parcourir de manière fiable des milliers de livrables internes et de produire des décisions et des résultats exploitables. À mesure que les modèles de pointe relèvent le plafond d’exécution, la différenciation repose sur les principes fondamentaux : rendre vos données accessibles, fournir une carte au système et opérationnaliser la fiabilité au moyen d’évaluations.
Les gains de capacité des modèles observés au cours de la dernière année indiquent très clairement la direction que prend ce secteur. En 2026, les leaders ont l’occasion d’agir rapidement. Choisissez un point d’entrée dont la valeur est manifeste, gagnez la confiance grâce à la provenance et aux garde-fous, puis transformez votre solution de recherche approfondie d’entreprise : de projet pilote, elle deviendra une capacité cumulative que l’entreprise utilise chaque jour.