Le RAG en entreprise, vraiment expliqué

Tu balances un document interne à ChatGPT. Il ne sait pas répondre.

Tu rebalances le même document avec un RAG entre les deux. Il répond précisément, avec les bons chiffres, le bon contexte, les bonnes nuances.

Même modèle. Même document. Une technique au milieu qui change tout.

Cette technique, c'est le RAG. Toutes les boîtes qui déploient sérieusement de l'IA en 2026 l'utilisent. Sans elle, ChatGPT, Claude ou Gemini sont incapables d'exploiter les données privées d'une entreprise.

Mais voilà ce qu'on ne te dit jamais. Le RAG basique, celui qu'on voit dans tous les tutos LinkedIn et dans 90% des démos d'agences IA, ne tient pas la route en production. Il a des modes d'échec bien identifiés que personne ne montre. Et ces échecs ne sont pas occasionnels, ils sont structurels.

Dans cet article, je vais te montrer trois choses. Comment fonctionne réellement un RAG, pourquoi il se plante si souvent dans la vraie vie, et ce que ça veut dire concrètement pour les entreprises suisses qui veulent vectoriser leurs données sans se tirer une balle dans le pied sur la confidentialité.

Pas besoin d'être technicien. Mais à la fin, tu sauras distinguer un projet IA sérieux d'une démo qui va exploser au premier vrai usage.

Le problème de fond : un LLM ne connaît pas tes données

Les grands modèles de langage, ChatGPT, Claude, Gemini, sont entraînés sur des quantités astronomiques de données publiques. Tout le web, des livres, des articles, du code, des forums. Des milliers de milliards de mots.

Mais 90% des données qui comptent vraiment dans une entreprise sont privées. Les mails, les documents internes, les procédures, les contrats, les bases Notion, les comptes rendus de réunion, les tickets support, les rapports que personne n'a jamais publiés.

Ces données, le modèle ne les a jamais vues.

Conséquence : posez à ChatGPT n'importe quelle question qui touche au fonctionnement réel d'une entreprise, et il ne peut pas répondre correctement. "Quelle est notre politique de remboursement ?" "Quel était le dernier accord signé avec ce fournisseur ?" "Que dit notre documentation produit sur cette fonctionnalité précise ?" Le modèle invente ou refuse.

Avant le RAG, deux options existaient. Soit tu réentraînais un modèle sur tes données privées, ce qui coûte des millions et reste irréaliste pour la majorité des entreprises. Soit tu te débrouillais sans IA réellement connectée à tes connaissances internes.

Le RAG a cassé cette équation. Au lieu de modifier le modèle, on construit un système autour du modèle qui va chercher les bonnes informations au bon moment. Le LLM reste généraliste, mais il devient capable d'exploiter des connaissances qu'il n'a jamais vues.

Tout repose sur une idée étonnamment simple : transformer le sens d'un texte en coordonnées mathématiques.

Deux notions à poser avant tout le reste

Avant d'aller plus loin, deux concepts à ancrer. C'est rapide, mais sans ça tout ce qui suit reste flou.

Un LLM, c'est un modèle qui prédit le mot suivant. Tu lui donnes un texte en entrée, il le continue. ChatGPT, Claude, Gemini, tous fonctionnent comme ça. Rien de plus magique.

Un vecteur, c'est une liste de chiffres. Par exemple [0.2, -0.5, 0.7]. Trois chiffres. C'est tout. Pourquoi c'est utile ? Parce que tout le RAG repose sur cette idée : transformer du texte en chiffres pour pouvoir le manipuler mathématiquement.

Étape 1 : transformer une montagne de texte en carte cherchable

Imagine une entreprise avec 10 000 documents internes. Des PDF, des contrats, des notes Notion, de la documentation technique, des mails. Tu veux que l'IA puisse répondre à n'importe quelle question dessus.

Premier problème : tu ne peux pas tout balancer d'un coup au modèle. Même les LLM à très long contexte ont une limite, et au-delà de quelques dizaines de pages, leur capacité d'attention s'effondre.

Deuxième problème : même si tu pouvais tout lui passer, comment le modèle saurait quoi chercher dans ce magma ?

La solution s'appelle l'indexation. C'est le travail invisible qu'on fait une fois, à l'avance, et qui rend tout le reste possible. Trois sous-étapes.

Le chunking : découper intelligemment

La première opération consiste à découper les documents en petits morceaux qu'on appelle des "chunks".

Pourquoi découper ? Parce que les modèles d'embedding qu'on va voir juste après ont une limite de taille. Ils peuvent traiter quelques centaines de mots à la fois, parfois quelques milliers, pas plus.

Mais la vraie question, c'est : découper en morceaux de combien, et où ?

Sur la taille, c'est un compromis. Trop petit (genre 50 mots), tu perds le contexte. Une phrase isolée sortie de son paragraphe peut ne plus rien vouloir dire. Trop grand (genre 5000 mots), c'est l'inverse, ton morceau contient trop d'idées différentes. Quand le modèle d'embedding va le résumer en un seul vecteur, il va mélanger toutes ces idées et le résultat sera flou. La recherche derrière sera imprécise.

En pratique, le sweet spot se situe entre 500 et 1000 mots par chunk.

Sur où couper, c'est plus subtil. Tu peux couper bêtement tous les 500 mots et tomber au milieu d'une phrase, au milieu d'une idée. C'est mauvais. Les systèmes sérieux essaient de couper aux frontières naturelles : fin de paragraphe, fin de section, fin de chapitre.

On ajoute presque toujours ce qu'on appelle un overlap, un chevauchement. Le chunk 1 va de 0 à 500 mots. Le chunk 2 va de 450 à 950 mots. Le chunk 3 va de 900 à 1400 mots. Comme ça, si une idée est à cheval sur deux chunks, elle apparaît dans les deux, et au moins un des deux la capture correctement.

Il existe des techniques plus avancées, comme le chunking sémantique, où on coupe quand le sujet change vraiment dans le texte. Mais ça devient technique, on garde ça pour un autre article.

Le truc à retenir : le chunking n'est pas un détail. Mal fait, c'est une des sources principales d'échec du RAG basique. Bien fait, c'est déjà la moitié du boulot.

Les embeddings : transformer le sens en mathématiques

Maintenant qu'on a nos chunks, on les transforme en vecteurs. Ces vecteurs s'appellent des embeddings.

Qui produit ces embeddings ? Un modèle d'embedding. Et c'est important de bien comprendre la différence avec un LLM.

Un LLM génère du texte mot après mot. Un modèle d'embedding ne génère rien du tout. Il prend du texte en entrée et il sort un vecteur. C'est tout ce qu'il sait faire, mais il le fait très bien.

Comment a-t-il appris à faire ça ? Il a été entraîné sur des milliards de textes avec un objectif simple : deux textes qui parlent de la même chose doivent finir avec des vecteurs proches. Deux textes sans rapport doivent finir avec des vecteurs éloignés.

Les modèles les plus connus aujourd'hui s'appellent Text Embedding 3 d'OpenAI, ou BGE en open source. Tu n'as pas besoin de retenir les noms, juste de savoir que c'est ce genre de modèle qui fait le travail.

Concrètement, chaque chunk devient une liste d'environ 1500 chiffres. Pourquoi 1500 ? Parce que chaque chiffre représente une dimension du sens.

Tu peux imaginer 1500 curseurs, chacun réglé sur une valeur précise. Un curseur capture peut-être à quel point le texte parle de cuisine. Un autre à quel point il est technique. Un autre à quel point il est émotionnel. Un autre s'il est formel ou familier. Et ainsi de suite, sur 1500 dimensions.

Évidemment, ces dimensions ne sont pas étiquetées comme ça dans la réalité. Le modèle a appris tout seul quelles dimensions étaient utiles. Mais le principe est là : chaque chunk se retrouve avec une position précise dans un espace mathématique à 1500 dimensions.

Et voilà la propriété magique : deux textes qui parlent de la même chose auront des embeddings très proches. Deux textes sans rapport auront des embeddings très éloignés.

Le stockage : la base vectorielle

Une fois qu'on a tous nos embeddings, on les stocke. Pas dans une base de données classique, parce qu'elle n'est pas conçue pour chercher des vecteurs proches. On les stocke dans une base de données vectorielle.

Pinecone, Chroma, Weaviate, Qdrant : ce sont les noms qui reviennent partout dans l'écosystème. Ces bases sont optimisées pour une seule chose : retrouver très vite les vecteurs les plus proches d'un autre vecteur, parmi des millions.

À la fin de l'indexation, l'entreprise possède quelque chose de précieux : une carte sémantique de ses connaissances internes. Chaque morceau de document a une position dans un immense espace mathématique. Plus deux contenus parlent de la même chose, plus ils se retrouvent proches sur cette carte.

Étape 2 : retrouver les bons morceaux quand quelqu'un pose une question

On a notre base vectorielle. Quelqu'un pose une question : "Quelle est notre politique de remboursement ?"

Quelque part dans les 10 000 chunks, la réponse existe. Mais comment la trouver, sachant que cette question, elle, n'est pas dans la base ?

L'astuce est belle de simplicité. On transforme la question en vecteur, avec exactement le même modèle d'embedding que celui qui a servi pour les documents. Puis on cherche les chunks dont les vecteurs sont les plus proches du vecteur de la question.

La recherche par k plus proches voisins (KNN)

Cette technique s'appelle la recherche par k plus proches voisins, en anglais KNN. Le k, c'est juste le nombre de chunks qu'on veut récupérer. En général 3 ou 5.

Visualise un instant. Imagine un espace à trois dimensions. Chaque chunk est un point dans cet espace. Ta question est aussi un point. Tu cherches les points les plus proches du point question. Tu en sors 3 ou 5. Voilà tes chunks pertinents.

En vrai on n'est pas en trois dimensions, on est en 1500. Mais le principe est strictement le même.

La similarité cosinus : comment mesurer "proche" en 1500 dimensions

Une question mérite qu'on s'arrête : comment on mesure la proximité entre deux vecteurs dans un espace à 1500 dimensions ?

La méthode la plus utilisée s'appelle la similarité cosinus. Au lieu de mesurer la distance entre deux points, on mesure l'angle entre deux flèches.

Chaque vecteur, tu peux l'imaginer comme une flèche qui part du centre de l'espace et qui pointe dans une direction précise.

• Deux flèches qui pointent dans la même direction : deux textes qui parlent de la même chose.
• Deux flèches perpendiculaires : deux textes qui n'ont aucun rapport.
• Deux flèches qui pointent dans des directions opposées : deux textes contraires.

La similarité cosinus, c'est juste un nombre entre -1 et 1 qui mesure cet angle. Proche de 1, c'est similaire. Proche de 0, ça n'a rien à voir. Proche de -1, c'est l'inverse.

Pourquoi mesurer l'angle plutôt que la distance brute ? Parce que la longueur de la flèche n'a pas vraiment de sens par rapport au contenu du texte. Ce qui compte, c'est où la flèche pointe.

Concrètement, quand l'utilisateur pose une question, le système calcule la similarité cosinus entre le vecteur de la question et tous les vecteurs de la base. Il les classe. Il garde les 3 ou 5 meilleurs. C'est ça, le KNN.

La génération : on colle les morceaux dans le prompt

On a nos 5 chunks pertinents. Qu'est-ce qu'on en fait ?

On les colle dans un prompt qu'on envoie au LLM. Ça ressemble à ça :

"Réponds à la question suivante en te basant uniquement sur le contexte ci-dessous.

Contexte : [les 5 chunks sélectionnés]

Question : [la question de l'utilisateur]"

Le LLM lit le contexte, lit la question, et génère une réponse ancrée dans ces chunks. Pas dans ses connaissances générales. Dans tes documents.

Voilà la magie du RAG. Le LLM reste un modèle généraliste qui n'a jamais vu tes données, mais il peut répondre comme s'il les connaissait.

Pourquoi le RAG basique se plante en production

C'est ici que la plupart des tutoriels s'arrêtent. C'est aussi ici que les vrais problèmes commencent.

Un RAG vanille fonctionne magnifiquement bien dans une démo de 30 minutes avec 50 documents propres. Tu le déploies sur 10 000 documents internes hétérogènes avec de vrais utilisateurs qui posent de vraies questions, et il se met à produire des réponses à côté de la plaque, à halluciner, à mélanger les sources.

Pas occasionnellement. Structurellement. Trois grandes faiblesses reviennent constamment.

Problème 1 : les utilisateurs posent de mauvaises questions

Le RAG dépend entièrement de la formulation de la question. Une question vague ou ambiguë va récupérer des chunks complètement hors sujet. Et si les mauvais chunks entrent dans le prompt, le LLM produit mécaniquement une mauvaise réponse.

Garbage in, garbage out.

Première parade : la Query Translation. Avant de lancer la recherche, on demande au LLM de réécrire la question plusieurs fois, sous différents angles. On lance la recherche sur chacune des reformulations et on combine les résultats. Cette technique s'appelle le Multi-Query Retrieval.

Deuxième parade, encore plus audacieuse : HYDE, pour Hypothetical Document Embedding.

L'idée est contre-intuitive. Au lieu de chercher avec la question, on demande au LLM d'inventer une réponse hypothétique. Pas pour l'afficher à l'utilisateur. Uniquement pour améliorer la recherche.

Concrètement, prenons la question "Quelle est notre politique de remboursement ?". C'est court, sec, abstrait. Maintenant on demande au LLM : "Imagine la réponse, même si tu ne la connais pas." Le LLM va inventer quelque chose comme :

"Notre politique de remboursement permet aux clients de retourner leurs produits dans un délai de 30 jours après l'achat. Pour bénéficier d'un remboursement, le produit doit être dans son emballage d'origine et accompagné d'une preuve d'achat. Le remboursement est effectué sur le moyen de paiement original sous 5 à 10 jours ouvrés."

Cette réponse est totalement inventée. Le LLM n'a aucune idée de ta vraie politique de remboursement. Mais ce qui est génial, c'est qu'on s'en fout. On ne va pas la donner à l'utilisateur. On va l'utiliser comme clé de recherche.

On vectorise cette fausse réponse et on cherche les vrais documents les plus proches dans la base.

Pourquoi ça marche mieux que de chercher avec la question directement ? Parce qu'une question fait 5 mots, alors qu'un vrai document de politique de remboursement en fait 200. La fausse réponse, elle, a le même vocabulaire, la même structure, le même niveau de détail qu'un vrai document. Sa signature dans l'espace vectoriel ressemble plus à celle des vrais documents.

C'est tout bête, mais c'est redoutablement efficace.

Problème 2 : les documents récupérés ne sont pas tous pertinents

Même avec une question bien formulée, on n'est pas sortis d'affaire. Quand le système récupère 5 chunks, ils ne sont pas forcément tous pertinents. Parfois deux ou trois sont à côté. Et ces chunks pourris polluent ensuite la génération. Le LLM les lit, en tient compte, et part dans une mauvaise direction.

Pour comprendre pourquoi ça arrive, il faut comprendre la limite fondamentale de la recherche par similarité cosinus.

Quand on compare le vecteur de la question et le vecteur d'un document, ces deux vecteurs ont été calculés séparément. Chacun a été résumé sans connaître l'autre. C'est rapide, ça permet de chercher dans des millions de documents en quelques millisecondes. Mais c'est grossier.

Le modèle d'embedding n'a pas vraiment lu la question et le document ensemble pour décider s'ils vont bien ensemble. Il a juste résumé chacun de son côté, puis on a comparé les résumés.

La parade s'appelle le re-ranking.

On prend la question et le document candidat, et on les passe ensemble dans un autre modèle qu'on appelle un cross-encoder. Ce modèle, lui, lit vraiment les deux en même temps, mot par mot. Il peut faire des liens fins entre tel mot de la question et tel mot du document. Il sort un score de pertinence beaucoup plus précis.

L'inconvénient : c'est lent. Très lent. Tu ne peux pas faire ça sur des millions de documents.

C'est pour ça qu'on fait les deux étapes en cascade :

Cette architecture en deux étapes est aujourd'hui une des briques essentielles des systèmes RAG sérieux. Elle change la qualité des réponses de façon spectaculaire.

Problème 3 : les hallucinations

Même avec les bonnes questions et les bons documents, un LLM peut halluciner. Il peut extrapoler, inventer, mélanger plusieurs sources, produire une réponse qui sonne juste mais qui est fausse.

C'est probablement le problème le plus critique pour les entreprises. Parce qu'un système IA qui répond faux avec assurance devient dangereux. Juridiquement, opérationnellement, stratégiquement.

Imagine un système qui cite une procédure interne abrogée depuis deux ans en disant "selon la procédure en vigueur". Imagine un assistant qui invente une clause contractuelle qui n'existe pas mais qui ressemble à ce que d'autres contrats contiennent. Imagine un agent qui mélange les politiques de deux clients différents et produit une réponse plausible mais incorrecte.

Le RAG vanille ne protège pas contre ça. C'est précisément pour cette raison que l'industrie a évolué vers une nouvelle classe de systèmes : les RAG correctifs.

Le RAG correctif : des systèmes qui se vérifient eux-mêmes

Les RAG modernes ne sont plus des chaînes linéaires qui vont du point A au point B. Ce sont des systèmes dynamiques qui bouclent, qui vérifient, qui se corrigent.

L'idée est simple à formuler. À chaque étape, on vérifie :

• Les documents récupérés sont-ils vraiment pertinents par rapport à la question ? Si non, on reformule la question et on relance la recherche.
• Si on ne trouve toujours rien de pertinent, on élargit la recherche (par exemple sur le web, si c'est autorisé).
• La réponse générée est-elle vraiment ancrée dans les documents fournis, ou est-ce que le modèle a inventé ? Si elle hallucine, on régénère.
• La réponse répond-elle effectivement à la question posée ? Si non, on recommence.

Ce n'est plus une chaîne, c'est un système qui boucle.

C'est exactement la direction prise par les papiers de recherche les plus cités sur le sujet ces dernières années : Self-RAG, Corrective RAG, Adaptive RAG. Tous portés par la même idée : le RAG vanille ne suffit pas, il faut ajouter de l'auto-vérification.

La différence pratique est énorme. Un RAG vanille suppose qu'il a raison du premier coup. Un RAG correctif part du principe qu'il peut se tromper et organise sa propre vérification.

C'est précisément cette différence qui sépare une démo impressionnante d'un système réellement exploitable en production.

L'angle suisse : ce que personne ne te dit sur tes données vectorisées

Jusqu'ici, on a parlé technique. Maintenant on parle de quelque chose qu'aucune vidéo TikTok, aucun tuto LinkedIn, aucune démo d'agence IA ne mentionne jamais : où vivent tes embeddings ?

Quand tu vectorises tes documents, tu ne les transformes pas en bouillie illisible. Tu les transformes en représentations mathématiques qui contiennent toujours leur sens. Cette différence est cruciale.

Un embedding reste une donnée personnelle

Beaucoup d'entreprises pensent qu'une fois leurs documents vectorisés, ils sont "anonymisés". C'est faux.

Un embedding capture le sens d'un texte. Des travaux de recherche (notamment Vec2Text, Morris et al., 2023) ont montré qu'il est possible de reconstruire approximativement le texte d'origine à partir d'un embedding, en particulier sur des chunks courts. Et même sans cette attaque complète, un embedding reste ré-identifiable : il pointe vers un chunk précis, qui pointe vers un document précis, qui contient des données précises.

Pour la nLPD (la nouvelle loi suisse sur la protection des données) comme pour le RGPD, un embedding qui peut être relié à une personne identifiée ou identifiable reste une donnée personnelle. Avec toutes les obligations qui vont avec.

Le vrai choix : où vivent tes vecteurs ?

Quand tu construis un RAG, tu fais en réalité plusieurs choix d'infrastructure, chacun avec ses implications.

Le modèle d'embedding. Si tu utilises l'API OpenAI ou Google, chaque chunk de tes documents transite par les serveurs du fournisseur. Selon les versions des conditions d'utilisation, les données peuvent ou non être conservées, utilisées pour de l'entraînement, transférées hors d'Europe.

La base vectorielle. Pinecone et Weaviate Cloud sont par défaut hébergés aux États-Unis, même si tous deux proposent désormais des régions européennes en option. Qdrant Cloud propose aussi des régions EU. Chroma peut tourner en self-hosted. Encore faut-il que le prestataire configure explicitement ces régions, ce qui n'est pas le réglage par défaut. Le choix de la base détermine où vivent physiquement tes vecteurs, donc indirectement la représentation mathématique de tes documents privés.

Le LLM final. Quand tu envoies au modèle le prompt avec ton contexte (qui contient des extraits réels de tes documents), tu envoies des données potentiellement sensibles. OpenAI, Anthropic et Google opèrent en grande partie hors Europe. Anthropic Claude est accessible via AWS Bedrock avec des régions européennes, notamment Frankfurt, ce qui change la donne en termes de juridiction.

Beaucoup d'entreprises se lancent dans un projet RAG sans se poser ces questions, ou en s'appuyant sur les promesses commerciales d'un prestataire qui leur dit que "les données sont sécurisées" sans préciser ce que ça veut dire.

La question à poser à n'importe quel prestataire RAG

Si quelqu'un te vend un projet RAG, voici les questions précises à lui poser :

• Quel modèle d'embedding est utilisé, et où tournent ses serveurs ?
• Où est physiquement hébergée la base vectorielle ?
• Quel LLM génère les réponses, et sous quelle juridiction est-il opéré ?
• Les données envoyées au LLM sont-elles conservées, et combien de temps ?
• Quelle est la chaîne de sous-traitance pour le traitement des données ?
• En cas de contrôle nLPD ou d'audit, peux-tu fournir la documentation de conformité ?

Si le prestataire bute sur l'une de ces questions, ce n'est pas un problème de communication. C'est un signal d'alerte sur la maturité du projet. Pour faire ce diagnostic chez toi sans engagement, mon audit IA gratuit couvre précisément ces points.

Les options réalistes en 2026

Il existe aujourd'hui des architectures qui permettent de construire un RAG sérieux sans envoyer ses données chez des acteurs hors Europe :

• LLM via AWS Bedrock Frankfurt : permet d'utiliser Claude ou d'autres modèles tout en restant dans une juridiction européenne avec des garanties contractuelles solides.
• Modèles d'embedding open source self-hosted : des modèles comme BGE ou les variantes multilingues d'E5 tournent très bien sur des serveurs européens, voire suisses, sans dépendance externe.
• Bases vectorielles auto-hébergées : Qdrant, Weaviate, Chroma peuvent tourner sur ton infrastructure ou chez un hébergeur suisse.
• LLM locaux pour les cas les plus sensibles : Llama, Mistral, Gemma tournent localement avec une qualité largement suffisante pour la plupart des cas RAG métier (extraction, résumé, Q&A factuelle). Sur les tâches de raisonnement complexe, les modèles propriétaires gardent une avance, mais ce n'est souvent pas nécessaire en RAG.

Ces architectures coûtent un peu plus cher à mettre en place que de balancer une API OpenAI. Elles demandent plus de compétences techniques. Mais elles te permettent de construire un système conforme, durable, et qui ne devient pas illégal du jour au lendemain quand un fournisseur change ses conditions ou qu'une nouvelle décision européenne sort.

Ce qu'il faut retenir

Le RAG, c'est trois étapes. On indexe ses documents en vecteurs. On retrouve les morceaux les plus proches d'une question. On génère une réponse ancrée dans ces morceaux. Trois étapes, et chacune peut faire foirer le système entier.

Le RAG basique se plante souvent. Pas par défaillance, mais structurellement. Mauvaises questions des utilisateurs, récupération imprécise par similarité cosinus seule, hallucinations du LLM. Si quelqu'un te vend un RAG sans parler de ces trois problèmes, il ne sait pas ce qu'il fait ou il ne te dit pas tout.

Le RAG sérieux est correctif. Reformulation type Multi-Query ou HYDE, re-ranking avec cross-encoder, vérification à chaque étape, boucles de correction. C'est ce qui sépare une démo de 30 minutes d'un système qu'on peut réellement mettre entre les mains d'utilisateurs en production.

Le RAG suisse est souverain. Tes embeddings restent des données personnelles. La question n'est pas "est-ce que ça marche" mais "où vivent mes vecteurs, sous quelle juridiction, et qui peut y accéder". Cette question, presque personne ne la pose. Elle est pourtant la plus importante pour les entreprises soumises à la nLPD ou au secret professionnel, comme les fiduciaires ou les avocats.

Le RAG vanille, c'est pour les démos.

Le RAG correctif, c'est pour la production.

Le RAG souverain, c'est pour la Suisse.

Si tu veux savoir où en est ta boîte sur ces questions, j'ai mis en place un audit IA gratuit. 15 minutes pour identifier les automatisations à forte valeur dans ton activité, en tenant compte de tes contraintes de confidentialité. C'est ici : audit.timekraft.ch.