RAG (Retrieval Augmented Generation) : le guide pratique pour PME

Le RAG est l'approche la plus rentable pour donner à un LLM accès à tes données internes — mais ce n'est pas une baguette magique sans qualité documentaire et bonne architecture d'embeddings.

C'est le constat qu'on fait chez CZMultimedia après avoir accompagné plusieurs PME sur des projets d'assistants IA internes. ChatGPT et Claude répondent brillamment à des questions générales, mais ils ne savent rien de ton catalogue produit, de tes procédures internes, de tes contrats, de l'historique de tes clients. Et fine-tuner un modèle sur tes données coûte cher, prend du temps, et devient obsolète à chaque mise à jour de la base documentaire.

Le RAG (Retrieval Augmented Generation) résout ce problème d'une manière simple : on récupère les bons extraits de tes documents au moment de la question, on les injecte dans le prompt, et le LLM répond en s'appuyant dessus. Pas de ré-entraînement, pas de modèle custom à maintenir. Mais pour que ça marche en production, il y a des règles d'architecture et de qualité documentaire qu'on ne peut pas ignorer.

Tu hésites entre RAG, fine-tuning ou chatbot scripté pour ton projet ? Contactez-nous

Sommaire

• Qu'est-ce que le RAG ?
• Architecture concrète : embeddings, vector DB, LLM
• Cas terrain : assistant interne PME en 3 semaines
• Quand le RAG est pertinent (matrice de décision)
• Quand le RAG ne suffit pas (limites et alternatives)
• Coûts réels et stack typique
• Checklist de mise en œuvre
• FAQ
• Conclusion

Qu'est-ce que le RAG ?

RAG signifie Retrieval Augmented Generation — littéralement "génération augmentée par la récupération". L'idée tient en une phrase : avant de répondre à une question, on cherche dans ta base documentaire les extraits les plus pertinents et on les colle dans le prompt envoyé au LLM.

L'analogie qu'on utilise souvent en réunion : c'est comme donner à un collaborateur compétent les bons documents avant qu'il rédige une réponse. Sans documents, il invente ou répond de mémoire. Avec les bons documents sous les yeux, il rédige une réponse précise, sourcée, et alignée sur ton contexte.

Le problème que le RAG résout

Quand tu poses une question à ChatGPT ou Claude sur un sujet interne à ton entreprise, trois choses peuvent se passer :

1. Le modèle dit "je ne sais pas" — frustrant mais honnête
2. Le modèle hallucine — il invente une réponse plausible mais fausse, beaucoup plus dangereux
3. Le modèle répond de manière générique — sans tenir compte de ta réalité métier

Aucune de ces situations n'est acceptable pour un assistant interne en production. Le RAG résout ça en injectant tes documents au bon moment.

Ce que le RAG n'est pas

• Ce n'est pas un nouveau modèle IA. Le RAG est une architecture qui s'appuie sur n'importe quel LLM existant (Claude, GPT, Gemini, Mistral, Llama).
• Ce n'est pas du fine-tuning. Tu ne touches pas aux poids du modèle. Tes documents restent dans ta base, à jour en temps réel.
• Ce n'est pas un chatbot scripté. Il n'y a pas d'arbre de décision codé en dur. Les réponses sont générées dynamiquement à partir des documents récupérés.
• Ce n'est pas un moteur de recherche enrichi. Un moteur de recherche te renvoie une liste de documents. Le RAG te renvoie une réponse synthétisée et sourcée.

Architecture concrète : embeddings, vector DB, LLM

Le RAG repose sur trois briques qui s'enchaînent. Voici comment ça fonctionne, sans jargon mais sans simplification abusive.

Étape 1 : l'indexation (faite une fois, puis en continu)

Tu prends tes documents (PDF, Word, pages Notion, articles de base de connaissance, tickets résolus, contrats…) et tu les transformes en représentation numérique exploitable par une machine. Ça se fait en trois sous-étapes :

Découpage en chunks : on coupe les documents en morceaux de 300 à 800 tokens (environ 200 à 600 mots). Trop petit, on perd le contexte. Trop grand, on noie l'information utile. Le bon réglage dépend du type de document — un contrat juridique se découpe différemment d'une FAQ produit.

Génération d'embeddings : chaque chunk passe dans un modèle d'embedding (OpenAI text-embedding-3-large, Cohere embed-v3, Voyage AI, ou un modèle open source comme bge-m3). Le modèle transforme chaque chunk en vecteur numérique de quelques milliers de dimensions. Deux textes au sens proche auront des vecteurs proches dans cet espace.

Stockage en vector database : les vecteurs et les chunks d'origine sont stockés dans une base spécialisée (pgvector, Qdrant, Pinecone, Weaviate). Cette base sait répondre vite à la question : "donne-moi les 10 vecteurs les plus proches de ce vecteur-ci".

Étape 2 : la requête (à chaque question utilisateur)

Quand un utilisateur pose une question, voici le flux complet :

Question utilisateur
    ↓
Embedding de la question (même modèle que pour l'indexation)
    ↓
Recherche des K chunks les plus proches dans la vector DB
    ↓
Re-ranking optionnel (modèle Cohere Rerank ou cross-encoder)
    ↓
Construction du prompt : système + chunks récupérés + question
    ↓
Appel au LLM (Claude, GPT, etc.)
    ↓
Réponse générée + citations des sources
    ↓
Affichage utilisateur

L'ensemble prend généralement entre 1 et 4 secondes selon la taille du corpus, le modèle d'embedding et le LLM choisi.

Étape 3 : le re-ranking (souvent oublié, souvent décisif)

La recherche vectorielle pure ramène des chunks "sémantiquement proches", mais pas toujours pertinents. Sur les projets sérieux, on ajoute systématiquement une étape de re-ranking : un modèle dédié (Cohere Rerank, ou un cross-encoder open source) ré-évalue les 50 premiers résultats et garde les 5 à 10 meilleurs.

C'est l'étape qui fait passer un RAG de "ça marche en démo" à "ça marche en production". On le constate sur tous les projets qu'on a menés : sans re-ranking, le taux de réponses pertinentes plafonne autour de 60-70%. Avec re-ranking bien réglé, on dépasse facilement les 85%.

Le rôle du LLM dans tout ça

Le LLM (Claude, GPT-4, Gemini, Mistral) intervient uniquement à la fin. Il reçoit un prompt qui ressemble à :

Tu es l'assistant interne de [Société]. Réponds à la question
de l'utilisateur en t'appuyant uniquement sur les extraits suivants.
Si l'information n'est pas dans les extraits, dis que tu ne sais pas.
Cite les sources.

[Extrait 1] : ...
[Extrait 2] : ...
[Extrait 3] : ...

Question : [question de l'utilisateur]

Le LLM ne "sait" rien sur ton métier. Il sait juste très bien synthétiser et reformuler à partir des extraits qu'on lui donne. C'est ce qui rend le RAG portable : tu peux changer de modèle sans toucher à l'indexation.

Tu veux qu'on évalue la faisabilité d'un RAG sur ta base documentaire ? Contactez-nous

Cas terrain : assistant interne PME en 3 semaines

Voici un cas concret, anonymisé, qui illustre ce que le RAG change dans une PME.

Le contexte

Un client industriel (PME, 80 collaborateurs, secteur fabrication mécanique) avait accumulé sur 15 ans une base documentaire massive : environ 12 000 PDF (fiches techniques produits, procédures qualité, comptes-rendus de non-conformité, modes opératoires, contrats fournisseurs). Tout ça était stocké sur un serveur de fichiers, organisé selon une arborescence métier que seuls 2 ou 3 anciens collaborateurs maîtrisaient vraiment.

Le problème quotidien : les nouveaux entrants — et même les anciens — passaient un temps considérable à chercher la bonne procédure, la bonne fiche produit, la bonne version d'un document. L'équipe support technique était sollicitée plusieurs fois par jour pour des questions dont la réponse existait déjà dans un PDF, quelque part.

Le diagnostic initial

Avant de partir sur du RAG, on a fait un audit du corpus. Les constats :

• Doublons : environ 18% des PDF étaient des copies ou des versions obsolètes du même document
• OCR manquant : 2 300 PDF étaient des scans non océrisés (donc invisibles à toute recherche)
• Métadonnées absentes : aucun PDF n'avait de tags, de dates de validité, ou de mention de version
• Documents périmés : environ 12% des procédures référençaient des produits qui n'étaient plus fabriqués

Ce diagnostic est crucial. Sans cette phase, on aurait construit un RAG performant qui aurait répondu avec confiance en s'appuyant sur des documents périmés. Catastrophe garantie.

Ce qu'on a mis en place

Sur 3 semaines (1 développeur senior + 0,5 ETP côté client pour le tri documentaire) :

Semaine 1 — Préparation du corpus

• OCR systématique des 2 300 PDF scannés (Tesseract + post-traitement)
• Déduplication par hash et similarité textuelle
• Tri manuel côté client des documents périmés à exclure
• Extraction des métadonnées disponibles (date, auteur, service)

Semaine 2 — Indexation et recherche

• Découpage en chunks de 500 tokens avec recouvrement de 100 tokens
• Embeddings via OpenAI text-embedding-3-large
• Stockage dans pgvector (PostgreSQL existant chez le client)
• Re-ranking via Cohere Rerank v3
• Construction du prompt système avec instructions strictes anti-hallucination

Semaine 3 — UI, sécurité, recette

• Interface web simple (Vue.js) avec authentification SSO existante
• Affichage systématique des sources citées (PDF + page)
• Logs des requêtes pour amélioration continue
• Tests utilisateurs avec 5 collaborateurs sur 30 questions réelles

Les résultats

Mesurés sur les 6 premières semaines après mise en production :

• Taux de réponses jugées pertinentes : 87% sur un panel de 200 questions évaluées par 3 référents métier
• Temps de recherche d'information : passé d'une moyenne de 8 minutes à environ 1 minute par requête (mesure avant/après auto-déclarée sur l'équipe support)
• Sollicitations du support technique sur des questions documentaires : réduites d'environ 70% (de ~25/jour à ~7/jour)
• Gain de temps support estimé : environ 6 heures par semaine sur l'équipe de 4 personnes

Le coût

Budget total du projet : environ 15 000 euros HT, dont :

• Développement (3 semaines) : ~12 000 euros
• Tri documentaire côté client : ~2 000 euros (en interne)
• Coûts récurrents mensuels : embeddings (~30 euros/mois après indexation initiale), Cohere Rerank (~50 euros/mois), API LLM Claude (~80 euros/mois), pgvector inclus dans l'instance PostgreSQL existante.

Soit environ 160 euros/mois en coûts récurrents, pour un gain de 6 heures/semaine sur du temps senior. Le ROI est atteint en moins de 4 mois.

Pour aller plus loin sur l'optimisation des temps de réponse et l'expérience utilisateur, c'est un sujet qu'on traite aussi dans notre article sur l'amélioration des performances des sites web, avec des leviers qui se cumulent côté front.

Quand le RAG est pertinent (matrice de décision)

Le RAG n'est pas une solution universelle. Voici une grille honnête pour évaluer son intérêt dans ton contexte.

Le RAG est pertinent si :

Le RAG est probablement prématuré si :

Le signal qui doit te faire passer au RAG

Si tu observes que tes équipes passent plus de 30 minutes par jour à chercher dans la documentation interne, et que tes outils de recherche actuels ne renvoient que des listes de fichiers à parcourir, c'est le moment. C'est le pain point qu'on retrouve sur la majorité des projets qu'on a menés.

Quand le RAG ne suffit pas (limites et alternatives)

Tout vendre en RAG est une erreur. Voici les cas où on recommande autre chose.

Limite 1 : les questions multi-documents complexes

Le RAG classique récupère 5 à 10 chunks. Si la réponse nécessite de croiser des informations dispersées dans des dizaines de documents (synthèse de jurisprudence, analyse comparative de fournisseurs sur 50 contrats), une recherche sémantique simple ne suffit plus. Il faut alors basculer sur des architectures plus avancées : RAG agentique, où un agent IA fait plusieurs requêtes successives, ou GraphRAG, qui exploite les relations entre entités.

Limite 2 : les données structurées

Le RAG est conçu pour du texte non structuré. Si tu veux qu'un assistant réponde à "quel est le chiffre d'affaires de mon top 3 clients sur Q1 2026 ?", la bonne réponse n'est pas un RAG : c'est un agent capable d'écrire et d'exécuter des requêtes SQL sur ta base de données. C'est exactement le type d'usage que des protocoles comme MCP facilitent côté outils métier.

Limite 3 : les domaines très techniques avec vocabulaire spécifique

Sur des corpus très techniques (médical, juridique, ingénierie spécialisée), les embeddings génériques ratent parfois la nuance sémantique. Deux solutions : utiliser un modèle d'embedding spécialisé (il en existe pour le médical, le juridique), ou compléter par du fine-tuning ciblé sur le modèle d'embedding (pas sur le LLM).

Limite 4 : la fraîcheur en temps réel

Si ta donnée change à la seconde (cours de bourse, stock en temps réel, statut d'une commande), indexer en RAG n'a pas de sens. Tu connectes l'IA directement à l'API en temps réel, via un agent ou un workflow d'automatisation.

Coûts réels et stack typique

On donne ici les ordres de grandeur qu'on observe sur les projets qu'on mène. Ce sont des fourchettes indicatives, à ajuster selon ton corpus.

Le coût d'indexation initiale

Pour un corpus de 10 000 documents (~5 millions de tokens) :

• Embeddings (OpenAI text-embedding-3-large) : environ 65 euros une seule fois
• Stockage vector DB : pgvector gratuit, Pinecone à partir de ~70 euros/mois pour cette taille

Le coût récurrent par requête

Une requête typique consomme :

• 1 appel embedding pour la question (~0,0001 euro)
• 1 appel re-ranking si activé (~0,002 euro)
• 1 appel LLM avec ~5 000 tokens en entrée et ~500 tokens en sortie. Sur Claude Sonnet 4.5 ou GPT-4o : entre 0,02 et 0,05 euro la requête.

Pour 1 000 requêtes par mois, on est autour de 30 à 60 euros par mois en coûts variables. Pour une PME, c'est négligeable face au gain de temps.

Stack typique CZMultimedia

Voici ce qu'on déploie par défaut, à adapter au contexte :

Vector database :

• pgvector (extension PostgreSQL) si le client a déjà une instance Postgres — gratuit, robuste, fonctionne jusqu'à plusieurs millions de chunks
• Qdrant en self-hosted si on veut un outil dédié — performant, open source, bonne UI
• Pinecone ou Weaviate Cloud si le client veut du managed sans ops

Modèle d'embedding :

• OpenAI text-embedding-3-large par défaut — bonne qualité, multi-langue, coût très bas
• Cohere embed-multilingual-v3 quand on veut la meilleure qualité multi-langue
• bge-m3 ou nomic-embed en self-hosted pour les contraintes RGPD strictes

Re-ranking :

• Cohere Rerank v3 — qualité élevée, intégration simple
• Cross-encoder open source self-hosted si contrainte de souveraineté

LLM générateur :

• Claude Sonnet 4.5 par défaut pour la qualité de synthèse
• GPT-4o ou Mistral Large selon contraintes
• Llama 3 70B ou Mistral Small en self-hosted si la souveraineté l'impose

Orchestration :

• LangChain ou LlamaIndex pour démarrer vite
• Code custom Python/TypeScript dès qu'on passe en production sérieuse — moins de magie, plus de contrôle
• n8n pour les workflows métier autour de l'agent

Budget global indicatif PME

Sur les projets qu'on a livrés, le ROI se mesure généralement entre 3 et 9 mois selon le volume d'utilisation.

Checklist de mise en œuvre

Avant de lancer un projet RAG, vérifie ces points. Si tu coches moins de 6 items sur 9, retourne d'abord traiter les prérequis.

FAQ

Quelle différence entre RAG et fine-tuning ?

Le RAG injecte tes documents dans le prompt au moment de la requête. Le LLM reste générique mais répond avec tes données contextuelles. Avantages : rapide à mettre en place, mise à jour en temps réel, traçabilité des sources, agnostique du modèle.

Le fine-tuning ré-entraîne un modèle sur ton corpus. Le modèle "absorbe" ton vocabulaire et ton style. Inconvénients : coûteux, plus lent à mettre à jour (chaque modification du corpus = nouveau ré-entraînement), risque d'oubli catastrophique sur les capacités générales, pas de citation possible.

En pratique, sur les projets qu'on a menés, le RAG suffit dans 90% des cas. Le fine-tuning n'est pertinent que si tu as un besoin très spécifique de style ou de vocabulaire qui ne peut pas être traité par un bon prompt système — par exemple un assistant juridique qui doit absolument adopter une rédaction très codifiée.

Quel coût pour mettre en place un RAG dans une PME ?

Trois fourchettes selon l'ambition :

• POC sérieux sur un sous-corpus représentatif (500 à 2 000 documents) : 5 à 10 jours de travail, soit 5 000 à 10 000 euros.
• Mise en production avec sécurité, monitoring, UI utilisateur : 3 à 6 semaines, soit 15 000 à 30 000 euros.
• Coûts récurrents (embeddings + vector DB + LLM + re-ranking) : généralement entre 100 et 300 euros par mois pour une PME, à ajuster selon le volume de requêtes.

Le budget total peut paraître élevé en valeur absolue, mais le calcul économique se fait en heures gagnées. Sur le cas industriel décrit plus haut, le ROI a été atteint en moins de 4 mois.

Quel vector database choisir ?

Notre recommandation par défaut :

• pgvector si tu as déjà PostgreSQL. C'est gratuit, robuste, et tu n'ajoutes pas un service supplémentaire à maintenir. Largement suffisant jusqu'à quelques centaines de milliers de chunks.
• Qdrant en self-hosted si tu veux un outil dédié, plus performant en pure recherche vectorielle. Bonne UI d'admin.
• Pinecone ou Weaviate Cloud si tu préfères du managed sans devoir gérer l'infrastructure.
• Au-delà de 5 millions de chunks ou si tu as besoin de fonctionnalités avancées (multi-tenancy fine, hybrid search natif), regarde plus sérieusement les solutions cloud spécialisées.

Le choix de la vector DB est rarement le facteur limitant. La qualité du chunking et du re-ranking compte beaucoup plus.

Combien de documents faut-il pour que le RAG soit pertinent ?

Pas de seuil minimum strict, mais des ordres de grandeur utiles :

• Moins de 50 documents : le RAG est probablement excessif. Une simple injection en contexte du LLM (les modèles modernes acceptent 100k à 1M de tokens) suffit largement.
• De 50 à 500 documents : le RAG commence à être utile, surtout si la base évolue régulièrement.
• De 500 à 50 000 documents : terrain de prédilection du RAG. La grande majorité des cas PME tombent dans cette catégorie.
• Au-delà de 50 000 documents : le RAG est indispensable. Mais on commence à devoir investir sérieusement sur l'architecture (filtres métadonnées, hybrid search, RAG agentique).

Plus important que le volume : la qualité. 500 documents propres et bien structurés battent 50 000 documents en doublons et obsolètes, à chaque fois.

Le RAG remplace-t-il un chatbot classique ?

Pas vraiment, et il ne devrait pas chercher à le faire dans tous les cas.

Un chatbot scripté (arbre de décision) reste pertinent pour des parcours fermés, reproductibles, à forte fréquence : "où est ma commande ?", "comment réinitialiser mon mot de passe ?". C'est rapide, prévisible, et ne nécessite pas de LLM.

Le RAG brille sur des questions ouvertes où la réponse dépend du contenu de tes documents : "quelle est la procédure exacte pour le contrôle qualité de la pièce X ?", "qu'a-t-on convenu avec ce fournisseur dans le contrat de 2023 ?".

En pratique, sur les projets qu'on a livrés, on combine souvent les deux : un premier niveau scripté pour les questions ultra-fréquentes (rapidité, coût zéro), un fallback RAG pour les questions hors-script (puissance, couverture). C'est aussi une bonne stratégie pour maîtriser les coûts d'API LLM.

Conclusion

Le RAG n'est pas une innovation magique. C'est une architecture pragmatique qui résout un problème concret : connecter un LLM à tes données internes sans investir dans un modèle custom.

Ce qu'il faut retenir :

• Le RAG est l'approche par défaut pour donner accès à un corpus documentaire à un assistant IA. Plus rentable que le fine-tuning dans 90% des cas.
• La qualité documentaire est le facteur n°1 de réussite. Audite ton corpus avant d'attaquer la technique.
• Le re-ranking n'est pas optionnel en production. C'est ce qui fait passer un RAG de "ça marche en démo" à "ça marche pour de vrai".
• Les coûts sont accessibles aux PME : 15-30k pour une mise en production sérieuse, 100-300 euros/mois en récurrent.
• Le RAG ne remplace pas tout : pour les données structurées, les requêtes multi-documents complexes ou la donnée temps réel, d'autres architectures sont plus adaptées.

Chez CZMultimedia, on accompagne les PME de la région lyonnaise et au-delà sur des projets d'automatisation et d'assistants IA basés sur le RAG. De l'audit du corpus à la mise en production, en passant par la formation des équipes pour entretenir la base dans la durée.

Contactez-nous pour qu'on évalue ensemble si le RAG est le bon levier pour ton projet — réponse sous 24h, sans engagement.