RAG expliqué simplement : architecture, outils, cas d'usage entreprise

#Pourquoi le RAG est devenu incontournable en entreprise

Les LLM comme GPT-4o, Claude 3.5 ou Mistral Large sont entraînés sur des données publiques avec une date de coupure. Ils ignorent vos contrats internes, vos bases produit, vos procédures RH, vos tickets support. La première réponse naïve à ce problème est le fine-tuning : réentraîner le modèle sur vos données. Résultat : coûteux (plusieurs dizaines de milliers d'euros pour un modèle 7B), lent à itérer, et inadapté dès que les données changent.

Le Retrieval-Augmented Generation (RAG) résout ce problème différemment. Plutôt que d'injecter les connaissances dans les poids du modèle, on les stocke dans une base externe et on les récupère dynamiquement à chaque requête. Le LLM reçoit alors un prompt enrichi du contexte pertinent — et génère une réponse ancrée dans vos données réelles.

Selon Gartner (Hype Cycle for AI 2025), plus de 60 % des projets LLM en entreprise utiliseront une forme de RAG d'ici fin 2026. Ce n'est pas un effet de mode : c'est une contrainte architecturale liée à la nature même des LLM.

#L'architecture RAG étape par étape

#Étape 1 — Embed : vectoriser les documents

Tout commence par la transformation de vos documents en vecteurs numériques (embeddings). Un modèle d'embedding (Ada-002 d'OpenAI, nomic-embed-text, e5-large ou bge-m3 pour le français) projette chaque fragment de texte dans un espace à haute dimension (typiquement 768 à 3 072 dimensions). Des textes sémantiquement proches ont des vecteurs proches dans cet espace — c'est la propriété fondamentale qui rend la recherche par similarité possible.

La qualité du chunking est critique ici. Un chunk trop court perd le contexte ; un chunk trop long dilue la précision de la recherche. La pratique industrielle converge vers des chunks de 256 à 512 tokens avec un overlap de 20 %, accompagnés d'un header de métadonnées (source, date, section). Le chunking sémantique (par paragraphe logique plutôt que par nombre fixe de tokens) donne de meilleurs résultats sur des documents techniques ou juridiques.

#Étape 2 — Store : la base vectorielle

Les embeddings sont indexés dans une base de données vectorielle optimisée pour la recherche ANN (Approximate Nearest Neighbor). Ces bases ne sont pas de simples serveurs de fichiers : elles implémentent des index spécialisés (HNSW, IVF-Flat, ScaNN) qui permettent de chercher dans plusieurs millions de vecteurs en quelques millisecondes.

Parallèlement aux vecteurs, chaque entrée stocke le texte original et ses métadonnées (source, date de création, niveau d'accès, segment client), ce qui permet des requêtes hybrides : filtrage métadonnées + similarité sémantique.

#Étape 3 — Retrieve : recherche par similarité

Lorsqu'un utilisateur pose une question, elle est elle-même vectorisée (avec le même modèle d'embedding). La base vectorielle calcule la similarité cosinus entre ce vecteur-requête et tous les vecteurs indexés, et retourne les k chunks les plus proches (typiquement k = 3 à 10).

Les pipelines avancés combinent cette recherche dense (sémantique) avec une recherche sparse (BM25 / TF-IDF sur les mots-clés exacts), une technique appelée hybrid search ou re-ranking. Cela permet de capturer à la fois la proximité conceptuelle et la précision lexicale — particulièrement utile pour les noms propres, les références produit ou les numéros de contrats.

#Étape 4 — Generate : la génération contextuelle

Les k chunks récupérés sont injectés dans le prompt du modèle de langage (LLM) avec une instruction système du type : «Réponds uniquement en t'appuyant sur les documents fournis. Si la réponse ne s'y trouve pas, dis-le clairement.»

Cette contrainte d'ancrage (grounding) est ce qui différencie un assistant RAG d'un LLM classique : les hallucinations sont structurellement réduites parce que le modèle génère à partir de passages réels, avec citation de source possible. Sur les pipelines que Nehos déploie, on observe une réduction des hallucinations de l'ordre de 70 à 85 % par rapport à un LLM nu, mesurée via RAGAS (Faithfulness score).

#Comparatif des bases vectorielles pour l'entreprise

#pgvector — La pragmatique

pgvector est une extension PostgreSQL qui ajoute un type vector et un index HNSW. Si votre stack repose déjà sur PostgreSQL, c'est la voie d'entrée naturelle : pas de nouvelle infrastructure, transactions ACID, jointures relationnelles natives avec vos autres tables.

Limites : les performances à l'échelle (>10 millions de vecteurs) restent inférieures aux solutions dédiées. pgvector convient pour des PoC, des bases de taille modérée (<5M documents) et les architectures qui privilégient la simplicité opérationnelle.

#Qdrant — La production-ready open source

Qdrant est une base vectorielle écrite en Rust, open source (Apache 2.0), disponible en self-hosted ou managed (Qdrant Cloud). Elle implémente HNSW avec filtrage de payload intégré, scalar quantization pour réduire l'empreinte mémoire, et une API gRPC/REST claire. C'est l'option que Nehos recommande pour les déploiements souverains (cloud privé, on-premise) avec des volumes >1M vecteurs.

Le filtrage par métadonnées est particulièrement performant : chercher parmi les contrats d'un client donné tout en maintenant la recherche sémantique ne dégrade pas significativement la latence, contrairement à certains concurrents.

#Pinecone — La simplicity-first managée

Pinecone est la référence SaaS, entièrement managée, avec une DX soignée et un time-to-first-query très court. Pertinente pour des équipes qui ne veulent pas gérer d'infrastructure. Inconvénients : coût élevé à l'échelle, données hébergées aux US (point d'attention RGPD), pas de déploiement on-premise.

#Weaviate — La plus complète pour les pipelines hybrides

Weaviate se distingue par son support natif du hybrid search (dense + BM25), ses modules d'inférence embarqués (embedding, re-ranking) et son schéma de données orienté graphe. C'est le meilleur choix pour les architectures RAG complexes qui mixent recherche textuelle, filtrage sémantique et raisonnement sur des entités liées.

Compte tenu du contexte réglementaire, Nehos privilégie systématiquement Qdrant (self-hosted OVH/Scaleway) ou pgvector pour les clients soumis aux contraintes de souveraineté des données.

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

#Cas d'usage B2B : où le RAG crée vraiment de la valeur

#Base de connaissances interne

C'est le cas d'usage le plus déployé. L'entreprise dispose de wikis Confluence, SharePoint, procédures PDF, notes de réunion — du contenu rarement à jour, difficile à retrouver. Un assistant RAG indexe l'ensemble, répond en langage naturel et cite la source. Sur un projet déployé pour un acteur de la distribution B2B, les tickets au support interne ont baissé de 43 % en 3 mois post-déploiement.

#Analyse et interrogation de contrats

Les directions juridiques et achats gèrent des centaines de contrats. RAG + chunking par clause permet d'interroger : «Quels contrats incluent une clause de force majeure liée à une pénurie d'approvisionnement ?» ou «Quel est le délai de résiliation dans les contrats signés avec nos fournisseurs européens ?». Le gain en temps est massif — une recherche manuelle qui prend 2 heures devient une réponse en 8 secondes.

#Support client niveau 1 et 2

Un assistant RAG connecté à la documentation produit, aux FAQs et aux tickets résolus peut traiter la majorité des requêtes de niveau 1 sans intervention humaine. Le point clé : le modèle ne génère pas de réponses inventées — il cite uniquement ce qui est dans la documentation validée. Sur un déploiement agents IA pour un éditeur SaaS, le taux de résolution sans escalade est monté à 67 % des tickets entrants.

#Veille réglementaire et conformité

Les entreprises soumises à des réglementations denses (RGPD, NIS2, DORA, réglementation secteur financier) peuvent indexer les textes officiels et les doctrines internes pour qu'un assistant réponde à des questions de conformité. Contrairement à une recherche plein texte classique, la recherche sémantique permet de trouver les passages pertinents même quand la terminologie utilisée dans la question diffère du texte légal.

→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.

#Les limites du RAG qu'on ne vous dit pas

Le RAG n'est pas une solution magique. Plusieurs problèmes structurels apparaissent en production :

Le «lost in the middle» effect. Quand plusieurs chunks sont injectés dans le contexte, le LLM a tendance à ignorer les passages au milieu du prompt. Des études (Liu et al., 2023 — Lost in the Middle) montrent que les positions extrêmes du contexte reçoivent plus d'attention. Solution : re-ranking des chunks avant injection et limitation du contexte à k=3 ou k=5 pertinents plutôt que k=10 dilués.

La qualité des documents source. RAG ne compense pas un corpus mal structuré. Des documents non OCR-isés, des PDF multi-colonnes mal parsés, du contenu contradictoire entre versions — tout cela génère des réponses confuses. Le pre-processing du corpus est souvent la phase la plus longue d'un projet RAG (30 à 40 % du temps total).

L'absence de raisonnement multi-hop. Si la réponse nécessite de croiser plusieurs documents (document A donne le client, document B donne le contrat de ce client, document C donne la clause litigieuse), un RAG simple échoue. Il faut passer à des architectures multi-step (RAG récursif, GraphRAG) ou à des agents IA capables d'orchestrer plusieurs requêtes successives.

La latence. Un pipeline RAG ajoute 200 à 800 ms par rapport à un appel LLM direct (embedding de la requête + recherche vectorielle + construction du prompt). Pour des cas d'usage temps réel (chatbot vocal, autocomplete), cette latence peut être rédhibitoire sans optimisation poussée.

La dérive documentaire. Si la base vectorielle n'est pas re-indexée quand les documents changent, le modèle répond sur des données obsolètes. Un pipeline d'ingestion en continu (Kafka, webhooks Confluence/SharePoint, webhooks S3) est non négociable pour les bases de connaissance évolutives.

#Quand fine-tuner plutôt que RAG ?

La question revient systématiquement lors de nos découvertes projet. La réponse de Nehos est tranchée : le RAG est le défaut, le fine-tuning est l'exception.

Le fine-tuning est pertinent dans trois cas précis :

1. Modifier le style ou le comportement du modèle — adopter un ton maison, un format de réponse propriétaire, un vocabulary spécifique métier introuvable dans les données d'entraînement publiques.
2. Améliorer les performances sur une tâche très étroite — classification de tickets dans une taxonomie interne, extraction d'entités spécifiques, parsing de formats structurés propriétaires.
3. Réduire la latence et les coûts sur un volume massif — un modèle 7B fine-tuné sur votre tâche peut surpasser GPT-4o sur cette tâche précise, avec un coût d'inférence 20× inférieur.

En revanche, fine-tuner pour «donner de la mémoire» au modèle sur des données qui changent est une erreur fréquente et coûteuse. Le modèle mémorise les patterns des exemples d'entraînement, pas les faits comme une base de données — et oublie d'autres connaissances par catastrophic forgetting. Pour tout besoin documentaire évolutif, le RAG reste supérieur.

La combinaison optimale pour les projets ambitieux : RAG + fine-tuning. Un modèle fine-tuné sur le style et les formats de l'entreprise, connecté à une base RAG pour les connaissances factuelles. C'est l'architecture que Nehos déploie dans ses missions de déploiement de solutions IA générative haut de gamme.

#Les outils d'orchestration : LangChain vs LlamaIndex

Deux frameworks dominent l'écosystème RAG :

LangChain : ecosystème très large, nombreux connecteurs (100+ sources de données), communauté massive. Pertinent pour les projets qui intègrent RAG dans des pipelines agents complexes ou des chaînes de traitement multi-étapes. La verbosité de l'abstraction peut être un frein pour des équipes qui préfèrent contrôler finement chaque étape.

LlamaIndex : focus explicite sur l'indexation et la récupération de données pour LLM. API plus lisible pour les pipelines RAG purs, meilleure gestion des structures documentaires hiérarchiques (PDF multi-niveaux, bases de connaissance arborescentes). Notre recommandation pour des projets RAG dédiés sans besoin de la surface d'agents LangChain.

Pour les LLMOps et l'opérationnalisation en production, ces frameworks s'intègrent avec des outils d'évaluation (RAGAS, TruLens, Arize Phoenix) et de monitoring (LangSmith, LangFuse) qui tracent la qualité des réponses en temps réel.

#Ce que fait Nehos différemment sur un projet RAG

La plupart des équipes qui lancent un projet RAG s'arrêtent au PoC. Le vrai défi n'est pas technique — c'est l'industrialisation. Chez Nehos, chaque projet RAG passe par une phase de discovery qui adresse :

• Audit du corpus : qualité des sources, formats, licences, niveaux d'accès, fréquence de mise à jour
• Stratégie de chunking adaptée à la nature des documents (contrats vs procédures vs emails)
• Choix d'infrastructure souverain (Qdrant on-prem ou pgvector) vs managé selon le profil RGPD
• Pipeline d'évaluation avec métriques Faithfulness, Answer Relevancy, Context Precision dès la phase de staging
• Plan de maintenance : re-indexation automatique, détection de dérive, alertes qualité

Consultez nos cas clients Nehos pour des exemples concrets de pipelines RAG déployés en production dans les secteurs industrie, legal-tech et services B2B.