Recherche hybride : les 6 façons de retrouver une information

Un mardi matin ordinaire, dans une entreprise de 300 personnes. Six collaborateurs cherchent une information. Aucun ne cherche la même chose, et aucune de leurs questions ne se résout par le même mécanisme.

• « Est-ce qu'on peut télétravailler trois jours par semaine ? »
• « Où en est la commande de JP Dupont, la référence XOD1132 ? »
• « Est-ce que ce client a un ticket support ouvert en ce moment ? »
• « Combien de commandes sont en retard sur le site de Lyon ? »
• « Combien de contrats sont rangés dans le dossier Clients 2026, et lesquels ? »
• « Quelles options sont incluses dans la gamme Horizon ? »

Ces six questions ont l'air de se ressembler. Techniquement, elles n'ont presque rien en commun : comprendre un sens, retrouver une chaîne exacte, appeler un système tiers, calculer un résultat, lire une arborescence. La sixième, on le verra, ne se joue même pas au moment de la question.

Et elles restent faciles, puisque chacune se règle par une seule voie. Un manager, lui, pose des questions qui en combinent plusieurs, dans un ordre qu'on ne connaît pas d'avance.

D'où la recherche hybride. Un assistant qui ne maîtrise qu'une de ces voies ne répondra qu'à une fraction des questions de vos équipes. Les six, donc, puis ce qui se passe quand il faut les enchaîner.

1. L'information est noyée dans un document : la recherche sémantique

« Est-ce qu'on peut télétravailler trois jours par semaine ? »

La réponse existe. Elle est page 34 d'un accord d'entreprise de 60 pages, dans un paragraphe qui ne contient ni le mot « trois » ni le mot « télétravail », mais la formule « modalités de travail à distance, dans la limite de 60 % du temps mensuel ».

Aucune recherche par mot exact ne trouvera ce passage. La recherche sémantique le trouve, parce qu'elle compare du sens plutôt que des mots : les documents sont découpés puis convertis en vecteurs, et la question passe par la même conversion. Deux formulations qui veulent dire la même chose se retrouvent voisines dans cet espace.

C'est la brique fondatrice du RAG, et celle que tout le monde branche en premier. À juste titre, elle est spectaculaire. Le problème commence quand on s'arrête là.

2. L'information tient dans un nom ou une référence : la recherche par mots-clés

« Où en est la commande de JP Dupont, la référence XOD1132 ? »

XOD1132 est une clé, pas un concept. Idem pour JP Dupont, Projet Atlas ou PRD-19-B. Ces chaînes n'ont pas de voisinage sémantique : un modèle d'embedding ignore que XOD1132 est plus proche de XOD1133 que de la politique de congés, et il n'a aucune raison de le savoir.

Sur ce type de requête, la recherche vectorielle seule ramène du bruit plausible. Il faut une recherche lexicale, qui retrouve la chaîne exacte là où elle apparaît.

Or vos équipes emploient ce vocabulaire toute la journée. Une entreprise parle en références clients, en codes projet et en acronymes maison bien plus qu'en concepts. D'où notre classement du « tout vectoriel » parmi les erreurs qui rattrapent un RAG après le POC : la démo passe, la production casse.

La recherche sémantique trouve ce que vous vouliez dire. La recherche par mots-clés trouve ce que vous avez écrit. Il vous faut les deux.

3. L'information n'est dans aucun document : l'outil connecté au SI

« Est-ce que ce client a un ticket support ouvert en ce moment ? »

Ici, ni le sens ni les mots-clés ne servent : l'information n'existe dans aucun document. Elle vit dans l'outil de ticketing, dans le CRM, dans l'ERP. Et comme elle change dans l'heure, l'indexer serait de toute façon une mauvaise idée.

Il faut donc appeler le système qui détient la donnée, au moment de la question. Via un serveur MCP quand l'éditeur en fournit un, ou via un outil sur mesure quand il faut se brancher sur une API interne. Le protocole MCP a rendu ce branchement beaucoup moins coûteux qu'il y a deux ans.

4. L'information n'existe pas encore, elle se calcule : la requête en base

« Combien de commandes sont en retard sur le site de Lyon, et quels clients sont concernés ? »

Cette réponse n'est écrite nulle part. Elle se calcule, en croisant des lignes de commande, des dates promises et un code site.

C'est le rôle d'un outil de requête en base de données : l'assistant traduit la question en requête SQL, l'exécute en lecture seule sur un périmètre autorisé, et rend le résultat. Vos données les plus fiables et les plus fraîches sont souvent là, dans des bases structurées que personne n'interroge parce qu'il faut passer par un ticket au service data. Nous avons développé ce point dans Vos bases de données sont une mine d'or.

5. La question porte sur les documents eux-mêmes : le catalogue documentaire

« Combien de contrats sont rangés dans le dossier Clients 2026, et lesquels ? »

Question piège pour un RAG classique. Une recherche sémantique va rapporter dix passages qui parlent de contrats, sans savoir les compter ni garantir qu'elle a tout vu. Sur une question d'inventaire, un système qui répond « environ une quinzaine » est pire qu'un système qui ne répond pas.

La question porte sur la base documentaire elle-même : son arborescence, ses chemins, ses sources, ses dates. Il faut un outil qui interroge le catalogue de façon déterministe, et non le texte.

C'est ce que fait notre interrogation du catalogue documentaire. Elle répond aux « combien », aux « liste les sous-dossiers de », aux « quels documents viennent de ce SharePoint », et elle sert aussi à localiser un fichier précis avant d'aller en lire le contenu.

6. L'information est là, mais illisible : le traitement sur mesure

« Quelles options sont incluses dans la gamme Horizon ? »

La réponse est dans un fichier que vous avez déjà indexé. Elle est dans un tableur de 40 colonnes, où chaque ligne est une référence et chaque colonne une option, avec des croix, des cellules fusionnées et trois lignes d'en-tête. Ou dans un plan d'implantation, ou dans un catalogue produit exporté d'un ERP.

Aucune des cinq méthodes précédentes ne sauvera ce fichier. Découpé en morceaux de texte comme un document ordinaire, un tableur produit des chunks du genre Horizon ; X ; ; X ; 2 ; ; oui. C'est syntaxiquement du texte, sémantiquement du bruit. Le passage sera peut-être retrouvé, mais il ne voudra rien dire, ni pour le modèle, ni pour l'utilisateur qui lira la citation.

Cette sixième voie est d'une autre nature : elle rend cherchable ce qui ne l'était pas. Elle intervient à l'indexation, pas au moment de la question.

Concrètement, notre traitement sur mesure associe un critère de déclenchement (un type de fichier, un motif dans le nom, une structure reconnaissable) et des règles d'extraction écrites pour ce format précis : ce que signifie chaque colonne, quelles lignes sont des totaux, quelle unité s'applique. Le fichier entre en tableur, il ressort en connaissance exploitable, avec ses citations.

Nous n'appliquons volontairement aucun traitement générique à tous les Excel. Un tableur sans son contexte métier reste de la donnée brute : la colonne « Montant » est en euros ou en dollars, le « Statut » est celui de la commande ou du projet. Un parsing automatique produit du bruit qui a l'air d'une réponse, et c'est le pire résultat possible.

Schéma des six voies complémentaires pour retrouver une information : en amont, à l'indexation, le traitement sur mesure des fichiers complexes ; puis, au moment de la question, la recherche sémantique, la recherche par mots-clés, l'outil connecté au système d'information, la requête en base de données et l'interrogation du catalogue documentaire, mobilisées par un même agent pour produire une réponse unique et sourcée

Quand une seule question en réclame plusieurs

Mes six exemples ont un défaut : ils sont trop propres. Chacun désigne sa voie presque tout seul.

Un directeur d'exploitation, lui, pose plutôt ça :

« Est-ce qu'on tient nos engagements avec Durand cette année ? »

Rien dans cette phrase ne dit où chercher, ni quels engagements sont visés, ni sur quelle période. Aucune des six voies ne suffit, et on ne peut pas décider à l'avance dans quel ordre les emprunter.

L'assistant doit d'abord trouver ce qui matérialise l'engagement : un contrat, un avenant, une convention de service. Voie 1, plus la 5 s'il faut localiser le bon fichier dans la bonne arborescence. Il y lit les seuils, délai de prise en charge, nombre d'interventions incluses, taux de disponibilité. Et il y apprend au passage que la période court sur l'année civile, pas sur douze mois glissants.

À ce moment seulement, il sait quoi demander à l'outil de ticketing. Voie 3 se déclenche, avec un filtre qu'il vient de découvrir dans le contrat. Si les volumes dorment dans une base plutôt que dans le ticketing, ce sera la voie 4. Puis il compare, et il répond.

La deuxième requête ne pouvait pas être formulée avant d'avoir lu le résultat de la première. Un agent mène une enquête là où un simple aiguillage se contente de router : il évalue ce qu'il obtient et décide s'il en sait assez pour répondre, ou s'il doit repartir chercher. Le principe est détaillé dans notre article sur le RAG agentique.

Deux conséquences, en général découvertes trop tard. La première, il faut savoir s'arrêter : une enquête consomme du temps et des tokens, et sans bornes sur le nombre d'allers-retours, le système devient lent et cher, donc inutilisable même quand ses réponses sont bonnes. La seconde, il faut tracer. Quand une réponse résulte de quatre appels à trois sources, l'utilisateur doit pouvoir vérifier d'où vient chaque élément. Sans citations, personne n'accorde sa confiance, et une réponse à laquelle on ne se fie pas ne sert à rien.

Ce que vous avez, sans doute, aujourd'hui

Le test est simple. Reprenez les six questions du début et posez-les à l'assistant que vous utilisez déjà.

Avec Copilot, vous êtes bien servi sur les questions 1, 2 et 5, tant que l'information est dans Microsoft 365. Vous vous arrêtez à la frontière de votre SI métier et de vos bases : les questions 3 et 4 restent sans réponse, ou renvoient une approximation. Et vos fichiers métier atypiques sont traités comme des fichiers ordinaires.

Avec un RAG développé en interne, vous avez presque certainement la 1, parfois la 2. C'est le chemin naturel, le vectoriel est ce qu'on branche en premier et ce qui fait une belle démo. Les autres voies demandent des intégrations, des droits d'accès et de l'exploitation, donc du travail après le POC.

Avec un moteur de recherche d'entreprise classique, vous avez la 2 et la 5, avec des filtres. C'est rapide et solide, mais il faut savoir quoi taper. Personne ne trouve la politique de télétravail en cherchant « télétravail » quand le document dit « travail à distance ».

Aucun de ces outils n'est mauvais, je tiens à le dire. Ils couvrent une partie du besoin, correctement. Le problème est que vos équipes découvrent l'autre partie en s'y cognant, question après question, et qu'elles arrêtent vite de demander.

L'approche Ask This Guy

Nous avons pris le problème par l'autre bout. Plutôt que d'optimiser une méthode de recherche, nous en avons câblé cinq, plus une sixième qui prépare le terrain, et nous avons mis un agent au-dessus.

C'est lui qui décide. Il reformule la question, choisit la ou les voies à emprunter, lit ce qu'il obtient, et juge s'il en sait assez. Sinon il relance, mieux ciblé, avec ce qu'il vient d'apprendre. Sur le cas Durand plus haut, il enchaîne documents puis ticketing sans que personne lui ait dit dans quel ordre. Et si le contrat vit dans un tableur de suivi maison, c'est le traitement sur mesure, configuré une fois, qui lui a permis de le lire correctement.

La documentation détaille la mécanique. Chaque élément de la réponse renvoie à sa source, quelle que soit la voie qui l'a trouvé.

Côté utilisateur, il n'y a rien à savoir de tout cela. Il pose sa question en français. C'est bien le minimum : demander à un commercial de choisir entre « recherche sémantique » et « requête SQL » avant de taper sa phrase, ce serait lui transférer un problème d'ingénierie.

Questions fréquentes sur la recherche hybride

Qu'est-ce que la recherche hybride ?

La recherche hybride consiste à combiner plusieurs méthodes de recherche complémentaires au lieu d'une seule. Au sens strict, elle associe la recherche sémantique (par le sens, via des embeddings) et la recherche par mots-clés (par correspondance exacte). Au sens large, elle intègre aussi l'appel à des outils métier, la requête en base de données et l'interrogation du catalogue documentaire, pour couvrir les questions dont la réponse n'est dans aucun document. S'y ajoute une voie en amont : le traitement sur mesure des fichiers complexes, qui rend exploitables des tableurs ou des catalogues qu'un découpage classique transformerait en bruit.

Quelle différence entre recherche sémantique et recherche par mots-clés ?

La recherche sémantique compare le sens : elle retrouve « modalités de travail à distance » à partir de la question « peut-on télétravailler ? ». La recherche par mots-clés compare les chaînes de caractères : elle retrouve la référence exacte XOD1132 ou le nom JP Dupont, que la recherche sémantique manque parce que ces chaînes n'ont pas de sens propre. Les deux sont nécessaires, car une entreprise manipule autant de concepts que de références internes.

Pourquoi la recherche vectorielle seule ne suffit-elle pas ?

Parce qu'une part importante des questions en entreprise porte sur des identifiants sans valeur sémantique (références produit, codes projet, noms de clients), sur des données vivantes stockées dans le SI, sur des chiffres à calculer en base, ou sur la structure même de la base documentaire. Elle échoue aussi sur les fichiers dont la structure porte le sens, comme les tableurs, qu'un découpage en texte réduit à des suites de cellules. Aucun de ces cas n'est correctement traité par la proximité vectorielle, qui reste pourtant l'unique mécanisme de beaucoup de projets RAG.

Comment un assistant sait-il quelle méthode de recherche utiliser ?

C'est l'agent qui décide, à partir de la formulation de la question et de la description des outils dont il dispose. Une question conceptuelle déclenche une recherche sémantique, une référence explicite déclenche une recherche par mots-clés, une demande de dénombrement déclenche une interrogation du catalogue. Sur les questions complexes, il en enchaîne plusieurs, en se servant du résultat de la première pour formuler la suivante, jusqu'à estimer qu'il en sait assez pour répondre.

Pourquoi un fichier Excel est-il mal exploité par un RAG classique ?

Parce que dans un tableur, le sens est porté par la structure autant que par le texte. Une cellule ne veut rien dire sans son en-tête de colonne, son unité et sa ligne de référence. Un découpage en morceaux de texte, qui fonctionne bien sur un contrat ou une procédure, produit ici des suites de valeurs sans contexte. Il faut un traitement adapté au format, qui reconstitue ce que signifie chaque colonne avant l'indexation.

---

Conclusion

Tout le monde sait répondre à la question facile, celle dont la réponse tient dans un paragraphe bien écrit d'un document bien rangé. Un assistant se juge sur les cinq autres : celles où l'information est ailleurs, où elle n'existe pas encore sous forme de texte, ou bien où elle dort dans un fichier que personne n'a pris la peine de rendre lisible.

Si vous voulez voir ce que donnent vos propres questions, celles que vos équipes posent vraiment, réservez une démo : nous partirons de vos sources réelles. Le détail de l'approche est sur la page RAG entreprise clé en main, et l'interrogation de vos bases sur Talk to Data.