Cependant, si beaucoup ont pu utiliser la recherche approfondie à titre individuel — pour rechercher et synthétiser des informations en ligne —, peu en ont bénéficié dans un contexte professionnel. Ce n’est pas faute d’utilité, bien au contraire, mais en raison de préoccupations plus générales concernant la fiabilité, la diversité des sources de données et la capacité d’un modèle à traiter de grandes quantités de contexte, notamment une multitude de types de fichiers.
Notre expérience de la création d’outils de recherche approfondie adaptés aux entreprises au cours des 12 derniers mois montre qu’une ingénierie réfléchie permet de plus en plus d’atténuer ces préoccupations. Dans cet article, nous examinons les principaux obstacles aux applications efficaces de recherche approfondie en entreprise, la manière de les surmonter et l’évolution que nous anticipons en 2026.
Le plafond d’exécution a considérablement augmenté. 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, notamment une plateforme de découverte de cibles thérapeutiques pour l’un des plus grands groupes pharmaceutiques mondiaux, nous avons vu les hallucinations de sources passer de 3-4 % à pratiquement zéro. En décembre, gpt-5.2 a encore accru la longueur de contexte effective. Résultat concret : nous pouvons désormais passer de centaines à des milliers de sources par recherche, sans sacrifier la fiabilité. Le principal obstacle n’est plus la capacité du modèle, mais ce qui aurait toujours dû l’être : vos données, vos évaluations et la conception de votre programme.
Stratégie de données : mieux vaut les rendre accessibles que les unifier. 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, politique et impose de s’engager prématurément avant de savoir quelles questions comptent vraiment. En 2026, l’approche pragmatique consiste à privilégier une connectivité parcimonieuse. Rendez les données accessibles grâce à des points d’ancrage riches en signaux (spécifications, politiques, SKU, clauses contractuelles), plutôt que d’attendre des années pour tout unifier. Les modèles de pointe peuvent désormais effectuer des « jointures souples » entre systèmes lors de l’inférence, en reliant des termes associés sans correspondances formelles. Vous conservez votre rapidité de déploiement et la possibilité d’ajouter des sources ultérieurement.
La navigation évite l’errance. Les données d’entreprise ne sont pas le Web. Elles sont éparses, pleines de conventions locales et ne comportent souvent qu’une seule source correcte pour un fait donné. Sans orientation, les modèles ont tendance à enchaîner 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, graphes de relations simples) permet au système d’atteindre rapidement et à moindre coût le bon contexte. Imaginez les conseils d’un collègue expérimenté à une nouvelle recrue : « Ajoute ces sites à tes favoris et parle à Ross si tu as des problèmes avec AWS. » Nul besoin de complexité. 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 : ordinaires, mais essentiels.
Analytique (périodiquement) : le système choisit-il les bons outils, suit-il des pistes de recherche pertinentes, sélectionne-t-il des sources fiables et sait-il quand s’arrêter ? L’évaluation repose généralement sur un LLM faisant office de juge, comparé à des exemples étiquetés.
Utilisateur (en continu) : taux d’achèvement des tâches, retours qualitatifs des utilisateurs avancés et analyses d’usage. Le test ultime. Avons-nous créé quelque chose que les gens trouvent utile ?
Le ROI 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 ROI, 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 vite. Paradoxalement, cette pression peut pousser les équipes à faire de mauvais choix. Il est tentant de commencer par des tâches à faible enjeu, car elles sont faciles à déployer et peu susceptibles de froisser qui que ce soit. Mais ces cas d’usage produisent 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 activités déjà coûteuses : des processus complexes à fort enjeu dont le coût actuel est visible. Les meilleurs cas d’usage observés concernent notamment la génération d’appels d’offres et de propositions, l’analyse du paysage scientifique et la recherche en investissement, où l’impact se mesure en taux de réussite, en délais réduits jusqu’aux essais et en rapidité de conviction, et pas seulement en heures économisées.
Le tournant de l’UX : de la discussion à la délégation, des réponses aux livrables. Nous pensons qu’il s’agit de l’une des évolutions de l’expérience utilisateur qui définiront 2026. Parmi les solutions récemment les plus adoptées, deux éléments se distinguent. À mesure que ces systèmes sont devenus plus fiables, les utilisateurs ont commencé à moins les traiter comme des chatbots à interroger et davantage comme des analystes auxquels déléguer des tâches. Deux éléments rendent cela possible : permettre aux équipes d’adapter les modèles de document et les critères d’arrêt à leurs processus, et d’exporter directement dans le format réellement nécessaire (note, présentation, brief, etc.), au lieu de leur demander de produire un livrable final à partir d’un fil de discussion. Lorsque ces deux éléments sont réunis, le système cesse d’être un outil de référence et devient le moyen d’accomplir le travail.
L’an dernier, nous avons présenté l’intégration de la recherche approfondie dans l’entreprise. Nous avons repris le paradigme de recherche approfondie centré sur le Web, initialement popularisé par OpenAI, et l’avons étendu aux sources de données propriétaires des entreprises sans perdre la traçabilité ni le contrôle. Nous avons également souligné que les systèmes de recherche approfondie ne devaient pas être considérés comme une rupture avec les systèmes RAG plus classiques, mais comme leur évolution.
À l’approche de 2026, ce n’est pas tant le concept de recherche approfondie qui a changé que le plafond de ce qu’il est possible d’exécuter.
Lorsque nous avons commencé à créer ces systèmes début 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 progrès majeurs sont apparus avec des modèles comme o3 et gemini-2.5-pro au cours des premiers mois de l’année. Ils étaient excellents pour leur époque et permettaient tout à fait de créer des applications robustes de recherche approfondie, jusqu’à un certain point. Cette limite se situait généralement autour de quelques centaines de sources. Au-delà, il fallait élaguer très fortement le contexte, sous peine d’obtenir une réponse lacunaire, un non-respect des instructions ou de franches hallucinations.
Si vous avez créé de tels systèmes, vous reconnaîtrez certains de ces modes de défaillance.
Pour illustrer concrètement ce point : mi-2025, nous avons commencé à créer une solution de recherche approfondie d’entreprise avec l’un des plus grands groupes pharmaceutiques mondiaux. Ce système vise à accélérer la découverte de cibles thérapeutiques, un processus par lequel les chercheurs identifient 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 disponible le plus performant était o3. Malgré ses solides performances, 3-4 % des réponses générées par ce modèle contenaient des sources qui ne lui avaient pas été fournies par des appels d’outils vers les sources de données propriétaires du client. Nous avons atténué ce problème au moyen de contrôles de citations a posteriori, qui signalaient les parties des réponses non étayées par le contexte fourni. Cette approche a permis de renforcer la confiance des parties prenantes dans l’outil lors de la phase initiale de validation du concept et nous a aidés à progresser rapidement. Nous avons toutefois poursuivi nos efforts pour réduire ces erreurs, en cherchant à atténuer les limites des modèles tout en répondant aux demandes des parties prenantes d’ajouter davantage de 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. Après le remplacement de o3 par gpt-5, nos évaluations ont montré que le taux d’hallucination de sources était immédiatement tombé à 0 %.
Pour être précis, cet indicateur vérifie strictement si le modèle cite un ID de document ou une URL qui ne figurait pas dans le contexte récupéré. À l’époque de o3 et auparavant, les modèles inventaient parfois des noms de fichiers ou d’articles plausibles pour combler les lacunes de leurs connaissances. gpt-5 nous a permis d’éliminer pratiquement cette pathologie précise.
Ce problème est distinct des erreurs de fidélité — citer le bon document, mais mal interpréter le texte —, qui restent un défi que nous gérons grâce aux contrôles a posteriori mentionnés précédemment.
Cela a levé un obstacle majeur. Nous avons alors commencé à tester le système afin de déterminer jusqu’où nous pouvions le pousser avec la nouvelle génération de modèles. Nous avons constaté que nous pouvions multiplier par environ dix le nombre de sources examinées lors d’une recherche approfondie, pour atteindre environ 3 000 à 5 000. La limite finale n’était plus le non-respect des instructions, mais les performances sur les contextes longs : 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.
Cette restriction a été partiellement atténuée par la sortie de gpt-5.2 à la mi-décembre. Nos bancs d’essai internes sur les contextes longs ont indiqué une nette amélioration des performances effectives, nous permettant 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 progrès dans les capacités brutes des modèles, les principaux obstacles à la création de systèmes performants de recherche approfondie se sont, à bien des égards, déplacés vers ce qui aurait toujours dû compter : vos données, vos évaluations et la manière dont vous organisez votre programme de recherche approfondie dans l’entreprise. Chacune de ces étapes exige des décisions pragmatiques sur ce qui produit réellement un effet dans la création d’un système de recherche approfondie.
La suite de cet article explique comment nous abordons ces décisions.
Il peut être tentant de traiter les projets de recherche en 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 évoluez dans un domaine où les entités centrales sont stables, les requêtes reproductibles et l’objectif final consiste à industrialiser le processus, l’unification peut produire de réels bénéfices. Les cas classiques incluent les jointures entre données clients et revenus, les données de prix du marché ou tout besoin de rapports fiables couvrant plusieurs systèmes.
Toutefois, en pratique, les dirigeants innovants d’aujourd’hui attendent autre chose des systèmes de recherche approfondie d’entreprise.
Alors que le ROI des dépenses d’IA fait l’objet d’une attention croissante, l’un des principaux objectifs des décideurs est de prouver rapidement la valeur dans la réalité désordonnée 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 une démarche lourde. Elle devient politique. Et elle vous oblige souvent à vous engager dans une direction avant d’avoir découvert quelles questions comptent vraiment.
Nous pensons donc que, pour créer des systèmes de recherche approfondie de pointe en 2026, le point de départ pragmatique est généralement le suivant : rendez vos données accessibles avant de chercher à les embellir.
Si vous envisagez raisonnablement d’ajouter des sources au fil du temps — comme la plupart des entreprises —, les connectivités plus parcimonieuses sont sous-estimées. Vous pouvez exposer des dizaines de sources derrière une interface de récupération cohérente. Le système pourra tout de même fonctionner et, surtout, vous conserverez votre capacité à livrer rapidement. Lorsque vous ajoutez de nouvelles sources, nul besoin de tout bouleverser. Il suffit de connecter un nouveau connecteur, d’expliquer au système central ce qu’il est et comment l’utiliser, puis de laisser les modèles poursuivre. Cela fonctionne parce que les modèles de pointe actuels peuvent effectuer des jointures souples entre plusieurs sources de données lors de l’inférence, en reliant « ID client » dans un système à « Référence client » dans un autre, sans que personne écrive de correspondance formelle. Nous ne sommes pas la seule équipe à raisonner ainsi. Nous ne sommes pas la seule équipe à raisonner ainsi : l’agent de données interne d’OpenAI est conçu pour permettre aux modèles de raisonner sur 70 000 jeux de données hétérogènes en rendant le contexte et les connexions accessibles au moment de la requête, plutôt qu’en imposant une unification complète en amont.
Une nuance mérite d’être explicitée : une intégration parcimonieuse n’est pas nécessairement superficielle.
L’intégration parcimonieuse 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 certaines informations comme des points d’ancrage : spécifications, politiques, définitions de produits, SKU, clauses contractuelles, etc. Vous n’avez pas besoin d’unifier tous les jeux de données pour rendre ces points d’ancrage puissants : il suffit d’un identifiant stable et de quelques relations riches en signaux.
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 la citez éventuellement. Mais lorsque nous concevons des structures de données utiles, nous voulons faire de cette recherche le point de départ d’une exploration contrôlée. Nous pourrions, par exemple, relier facultativement l’enregistrement de cette spécification à des livrables historiques pertinents. Le terme « pertinent » peut ici avoir plusieurs sens, généralement selon la tâche réalisée par le système. Il peut s’agir d’appels d’offres mentionnant la spécification, d’anciennes réponses ayant remporté des marchés correspondants, de modifications demandées par le service juridique sur cette spécification, etc. Cette approche peut considérablement améliorer la qualité des réponses et la latence, en présentant rapidement au système de recherche approfondie les informations les plus essentielles au moment de la requête.
Cela soulève la question suivante : une fois que vous disposez d’un ensemble de sources reliées de manière parcimonieuse par quelques connexions riches en signaux, comment empêcher le système de recherche approfondie d’errer comme un enfant dans une confiserie et l’amener à naviguer comme un analyste expérimenté ?
Les sources de données d’entreprise ne se comportent pas comme le Web. Elles sont éparses, pleines de conventions locales et ne comportent souvent qu’une seule « bonne » source pour un fait donné, à condition de la trouver. De plus, les modèles actuels ont tendance à toujours maximiser le rappel pour les questions de recherche, en enchaînant souvent les requêtes pour trouver une seule source de plus, au détriment de la latence et de la patience des utilisateurs. Une formulation soigneuse des instructions peut atténuer ce phénomène.
La solution la plus efficace consiste à fournir 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’ontologie. D’autres parlent de couche sémantique, de service de recherche, de graphe ou de référentiel de concepts. Le terme importe peu.
L’essentiel est de fournir au système des actions rapides et peu coûteuses, afin que le modèle puisse passer efficacement d’un élément de contexte pertinent à l’autre au lieu d’errer pendant une éternité.
Une métaphore simple consiste à imaginer que vous venez de rejoindre une entreprise ou un nouveau projet et que vos collègues vous disent : « Tu dois ajouter ces sites à tes favoris, tu les utiliseras tout le temps », ou « chaque fois que tu as un problème avec AWS, parle à Ross : il te donnera les informations nécessaires », et ainsi de suite. De même, nous cherchons simplement ici à 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 entretenu manuellement. Les meilleures mises en œuvre que nous ayons trouvées sont soit générées par des LLM pendant le pipeline d’ingestion — avec extraction d’entités pour alimenter automatiquement le graphe —, soit de simples passerelles vers des systèmes de référence existants, comme une recherche via l’API Salesforce. Voici quelques exemples courants :
Recherches dans une table de hachage, par exemple interroger avec un nom de produit pour obtenir sa description
Une recherche légère des relations « courantes », par exemple les maladies auxquelles ce gène est le plus souvent associé dans notre graphe de relations causales entre gènes
Modèles de reconnaissance d’entités nommées, surtout utiles dans les domaines présentant des problèmes complexes de désambiguïsation des entités, comme l’industrie pharmaceutique
Pour les relations de données les plus complexes, des graphes RDF légers peuvent constituer la solution d’ontologie la plus extensible
… et bien plus encore
Une fois ce dispositif en place, le système peut parcourir efficacement vos sources de données. La question suivante est simple : comment savoir s’il fait systématiquement ce qu’il faut en conditions réelles d’utilisation ?
Vos données étant désormais accessibles et votre couche de navigation fournissant une carte, votre système est maintenant capable d’accomplir le travail. Mais, dans un contexte professionnel, la capacité ne vaut rien sans la 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 ressenti ». 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 manière autonome 5 000 documents afin de formuler une recommandation sur une décision de chaîne logistique valant plusieurs millions.
Le changement essentiel est que vous n’évaluez plus un modèle, mais un système. L’interprétation des questions, la planification, l’appel et l’interprétation des outils, l’élagage du contexte, le reclassement et même des détails apparemment banals des connecteurs, tels que 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 globalement répartir les évaluations en trois catégories, des plus mécaniques aux plus subjectives.
C’est la partie qui se rapproche le plus des tests unitaires et celle où les équipes peuvent souvent progresser le plus vite au début. Ce sont aussi généralement les évaluations les plus stables dans le temps : une fois configurées, elles restent bénéfiques pendant toute la durée du projet.
Les « évaluations mécaniques » sont généralement des contrôles pouvant être exécutés à chaque requête sans intervention humaine. Elles nous aident à vérifier que le système se comporte de manière prévisible et sûre sous des charges utilisateur 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 un document entier 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 adressées aux outils ? A-t-il réessayé de manière judicieuse lorsque des erreurs ont été renvoyées ?
Budgets de latence et de coût : 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 ?
Cela peut sembler banal, mais ce sont précisément les tests qui empêchent un système d’entreprise de se dégrader.
Prenons un exemple concret : dans notre projet de recherche approfondie pour la découverte de cibles thérapeutiques, nous avons utilisé deux niveaux de contrôle des citations exécutés à chaque requête. Tout d’abord, lors de la génération d’une réponse, nous demandons au modèle de produire fréquemment des citations intégrées au texte. La capacité des LLM à le faire de manière fiable est elle aussi relativement récente, puisqu’elle est apparue au premier semestre 2025. Quiconque a tenté auparavant de le faire avec des volumes de données significatifs comprendra la difficulté que cela représentait. Nous pouvons ainsi effectuer de simples contrôles par expressions régulières pour déterminer, par exemple, si un lien vers un article absent des sources fournies est mentionné.
Le deuxième niveau de contrôle intervient après la diffusion en continu de la réponse. La réponse est d’abord divisée en blocs, puis chacun est évalué : le système recherche dans les données récupérées des sources étayant les affirmations du bloc. Si aucun élément probant n’est trouvé, le passage est signalé comme une hallucination potentielle.
Si les évaluations mécaniques sont vos tests unitaires, les évaluations analytiques sont votre revue de code.
Nous cherchons ici à déterminer si le système accomplit bien son travail. Nous cherchons généralement à savoir s’il utilise les bons outils, suit les bonnes pistes de recherche, choisit les sources les plus fiables ou sait quand s’arrêter, entre autres.
En pratique, elles prennent généralement la forme d’une série de paires question-réponse (Q-R), pour lesquelles on connaît, par exemple, un ordre pertinent d’appel des outils ou la bonne décision à prendre compte tenu d’un corpus trouvé avec le premier outil. Les paires Q-R ne doivent pas nécessairement correspondre exactement aux entrées et sorties du système complet de recherche approfondie : ces méthodes permettent aussi de tester des sous-processus. À partir de ces étiquettes, produites par une personne ou un modèle d’étiquetage performant — notion ici relative —, nous pouvons utiliser un LLM comme juge pour noter les recherches et évaluer leurs performances. En suivant ces scores dans le temps, nous pouvons déterminer si nos modifications améliorent le système dans la direction souhaitée ou si elles ont entraîné une régression des performances.
Compte tenu du coût supérieur de ces exécutions en temps et en argent, elles doivent généralement être effectuées périodiquement, selon un calendrier défini ou avant les mises à jour de version.
Il existe aussi un intéressant bénéfice indirect : ces évaluations analytiques peuvent directement guider l’amélioration des connexions parcimonieuses évoquées plus haut. Si vous constatez que le modèle effectue régulièrement le même rapprochement pertinent — par exemple, « spécification → exemples d’appels d’offres historiquement pertinents » —, même lorsque les humains ne relient pas explicitement ces livrables aujourd’hui, c’est une information utile. Vous pouvez transformer ce rapprochement en relation ou raccourci de premier ordre, afin que les recherches futures bénéficient d’une latence réduite et d’une cohérence accrue.
C’est aussi là que vous repérez l’une des pathologies les plus coûteuses des systèmes de recherche approfondie : la tendance à maximiser le rappel par défaut. Un modèle peut toujours trouver une source de plus. La question est de savoir s’il le devrait. Nous pouvons ajuster le modèle pour renforcer un comportement d’arrêt pertinent : le système reconnaît alors qu’une récupération supplémentaire ne changera probablement pas 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 utilisateur 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 deux fois. Dans un contexte professionnel, c’est ce qui distingue un déploiement réussi d’un projet de recherche coûteux.
Les évaluations utilisateur visent fondamentalement à déterminer si le système résout le bon problème de la bonne manière. Cela signifie aller au-delà de « a-t-il donné la bonne réponse ? » et demander « m’a-t-il donné quelque chose d’exploitable ? »
En pratique, les évaluations utilisateur prennent généralement plusieurs formes :
Études d’achèvement des tâches : les utilisateurs peuvent-ils réellement accomplir leur travail plus vite ou mieux grâce au système ? Il ne s’agit pas de savoir si le modèle pourrait répondre à une question, mais si un véritable utilisateur, dans son processus réel, a obtenu ce dont il avait besoin.
Boucles de retours qualitatifs : échanges structurés réguliers avec les utilisateurs avancés. Quelles requêtes exécutent-ils de manière répétée ? À quel moment perdent-ils confiance ? Quand abandonnent-ils pour revenir à l’ancienne méthode ? Ces sessions révèlent souvent des modes de défaillance qui n’apparaissent jamais dans vos jeux de tests, car les utilisateurs posent leurs questions d’une manière imprévue ou appliquent des exigences de qualité implicites dont vous ignoriez l’existence.
Analyse de l’usage : quelles requêtes sont relancées ? Quelles réponses sont copiées et utilisées ailleurs ? À quel endroit les utilisateurs cliquent-ils sur le pouce vers le bas ? Une baisse de l’usage n’est pas toujours un échec — les utilisateurs obtiennent parfois leur réponse et passent à autre chose —, mais les tendances concernant le moment et la manière dont ils abandonnent les requêtes en disent long sur les attentes auxquelles le système ne répond pas.
Ensemble, ces approches permettent de mesurer l’utilité sans conjectures et de repérer les problèmes avant qu’ils n’érodent la confiance des utilisateurs.
Toutefois, même un système qui obtient un score parfait en précision mécanique et enchante ses premiers utilisateurs peut échouer au test ultime : accroître le chiffre d’affaires de l’entreprise. La fiabilité et la satisfaction des utilisateurs n’en sont que des conditions préalables. Pour franchir le fossé entre un projet pilote réussi et un actif transformateur pour l’entreprise, vous devez aller 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 se sont récemment beaucoup intéressés à cette question, à juste titre. Après des rapports tels que l’affirmation du MIT selon laquelle 95 % des projets d’IA d’entreprise n’atteignent pas leur ROI, 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 ce système de manière à créer de la valeur pour votre entreprise ?
La bonne nouvelle est que les systèmes de recherche approfondie de pointe reposant sur les principes ci-dessus sont bien placés pour atteindre cet objectif. Ils ne cherchent pas à tout automatiser ni à remplacer des métiers entiers. Ils cherchent à rendre vos meilleurs collaborateurs considérablement plus efficaces dans les activités à forte valeur qu’ils exercent déjà.
Mais pour passer d’un système « techniquement fonctionnel » à un système « générant un ROI », quelques leviers supplémentaires sont nécessaires : les choix relatifs à l’organisation, à l’expérience utilisateur (UX) et aux mesures, qui déterminent si le système deviendra un outil quotidien ou un onglet oublié.
D’après notre expérience, ils sont au nombre de deux.
Il est souvent tentant de commencer par des tâches internes à faible enjeu, comme « résumer cette réunion ». Bien que sûrs, ces cas d’usage prouvent rarement une valeur suffisante pour justifier leur coût.
Les systèmes de recherche approfondie sont les plus efficaces 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é génère une hausse démontrable des revenus ou un avantage stratégique.
Nous observons le ROI le plus élevé lorsque les entreprises ciblent des points d’entrée tels que :
Génération de propositions complexes et de réponses aux appels d’offres : les systèmes de recherche approfondie peuvent automatiquement retrouver les succès historiques les plus proches, ainsi que les échecs, extraire les quelques clauses qui déclenchent toujours des modifications, trouver les preuves les plus solides pour une exigence donnée, puis transformer le tout en un positionnement cohérent et convaincant pour l’appel d’offres. L’indicateur n’est pas ici le temps gagné, mais le taux de réussite, la préservation des marges et la réduction des mauvaises surprises juridiques ou commerciales en fin de processus.
Analyse du paysage scientifique : dans les organisations à forte intensité de R&D — industrie pharmaceutique, biotechnologies, semi-conducteurs —, le point d’entrée consiste à condenser des semaines de littérature et de connaissances internes en une orientation de recherche exploitable. Un système de recherche approfondie peut lire des milliers d’articles, brevets, rapports internes, notes de laboratoire et bilans de programmes antérieurs afin de cartographier les connaissances établies et les points contestés, puis produire un panorama étayé par des preuves. Il permet ainsi d’accélérer les cycles d’itération, de réduire les pistes sans issue et, surtout, de raccourcir le délai avant le premier essai sur l’humain.
Analyse de marché : pour les banques et les fonds spéculatifs, la valeur réside dans la transformation de recherches internes fragmentées — notes, modèles, transcriptions, commentaires de courtiers — et de signaux externes — déclarations, résultats, indicateurs macroéconomiques, actualités — en aide à la négociation adaptée à la prise de décision. Un système de recherche approfondie peut continuellement élaborer et actualiser une analyse d’une entreprise, d’un thème ou d’une question macroéconomique, faire ressortir les principales évolutions depuis la semaine précédente, réconcilier les sources contradictoires et produire une note d’investissement ou un dossier de transaction entièrement traçable.
Le point commun est qu’il ne s’agit pas de conversations. Il s’agit de processus complexes qui nécessitent généralement des consultants externes coûteux ou plusieurs semaines de travail de collaborateurs expérimentés. Lorsque vous appliquez un système de recherche approfondie à ces problèmes, sa valeur est indéniable.
Il s’agit de l’une des évolutions de l’expérience utilisateur qui définiront 2026.
Si votre système de recherche approfondie n’est qu’un chatbot que les utilisateurs interrogent pour trouver des informations, son utilisation peut rapidement devenir sporadique. Il reste un outil de référence, et les utilisateurs doivent finalement assembler eux-mêmes les résultats pour obtenir le livrable souhaité. Mais s’il se comporte comme un analyste toujours disponible auquel on peut confier du travail, il peut entièrement transformer le modèle opérationnel de l’équipe.
Nous observons un passage de la « discussion » — de brefs échanges successifs — à la délégation : définir un périmètre, un modèle de document et un objectif, puis laisser le système travailler.
Trois évolutions précises rendent cela possible :
Des résultats sous forme de livrables : les travaux à forte valeur vivent rarement dans une fenêtre de discussion ; ils prennent la forme de documents, de notes et de présentations. Les systèmes modernes de recherche approfondie doivent contourner la phase de discussion et générer directement le livrable professionnel final. Lorsqu’un utilisateur peut demander « une note d’investissement de trois pages au format de notre entreprise » et recevoir un fichier téléchargeable plutôt qu’un flux de texte, le délai de création de valeur chute fortement. Cette approche s’étend aussi fréquemment aux générations planifiées : les utilisateurs peuvent demander que des e-mails ou des rapports contenant de nouvelles analyses soient automatiquement générés et distribués aux personnes concernées à mesure que de nouvelles données apparaissent.
Optimisation locale grâce à des modèles de document personnalisés : les modèles sont devenus suffisamment robustes pour permettre aux unités opérationnelles, voire aux utilisateurs individuels, d’adapter leurs propres instructions et comportements sans déstabiliser le système. Un rapport sur les risques ne se présente pas de la même manière à Londres et à New York. En permettant aux équipes d’importer 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, vos utilisateurs peuvent tirer beaucoup plus de valeur du système et créer un outil qu’ils souhaitent utiliser toujours 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 un enjeu prioritaire. Vous ne pouvez pas présenter une boîte noire. L’interface doit rendre visibles le raisonnement et les choix du système, en montrant à l’utilisateur les outils employés, en générant des citations, et plus encore. Nous constatons souvent que la meilleure UX pour ces systèmes présente par défaut une vue d’ensemble de l’avancement de la recherche, tout en permettant à l’utilisateur d’approfondir en développant des informations supplémentaires dans une barre latérale ou un élément similaire.
Nous imaginons un avenir où chaque entreprise de premier plan disposera d’un système de recherche approfondie sur mesure au cœur de ses processus les plus essentiels. 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, les fondamentaux deviennent les facteurs de différenciation : rendre vos données accessibles, fournir une carte au système et rendre la fiabilité opérationnelle grâce aux évaluations.
Les progrès des capacités des modèles observés au cours de l’année écoulée sont le signal le plus clair de la direction prise. En 2026, les dirigeants ont l’occasion d’agir rapidement. Choisissez un point d’entrée dont la valeur est évidente, gagnez la confiance grâce à la traçabilité et aux garde-fous, puis transformez votre solution de recherche approfondie d’entreprise : d’un projet pilote, faites-en une capacité cumulative utilisée quotidiennement par l’entreprise.