RAG pour PME : connecter un agent IA à votre base de connaissance sans le faire halluciner (2026)

TL;DR

• Un agent IA générique ne connaît pas vos documents. Le RAG (retrieval augmented generation) est la brique qui va chercher la bonne information dans votre base au moment de la question, et la donne au modèle pour qu'il réponde sur du factuel, pas sur ses souvenirs d'entraînement.
• RAG contre fine-tuning : le fine-tuning apprend un style, le RAG apporte des faits à jour. Pour 9 PME sur 10, c'est RAG, parfois les deux, presque jamais le fine-tuning seul.
• Les fenêtres de contexte géantes n'ont pas tué le RAG. Sur le coût, la fiabilité (phénomène lost in the middle documenté dès 2023) et la scalabilité, la récupération ciblée reste la fondation.
• Le coût qui surprend : l'embedding de 10 000 documents revient à environ 0,10 USD. Le vrai budget, c'est le temps d'ingénierie pour que le système retrouve la bonne information, pas l'infrastructure.
• Quand un RAG hallucine, le coupable est presque toujours la récupération, pas le modèle. Quatre leviers règlent ça : découpage propre, recherche hybride, reranking, et un prompt qui interdit d'inventer.

Pourquoi cet article maintenant

Fin 2025, un cabinet de conseil RH de la région lilloise (40 salariés, environ 600 conventions collectives et accords d'entreprise à maîtriser) nous appelle après un premier essai raté. Ils avaient branché un assistant IA grand public sur quelques documents, demandé "quel est le délai de préavis pour un cadre dans la convention Syntec ?", et reçu une réponse précise, formatée, confiante. Et fausse. Le modèle avait inventé un chiffre plausible parce qu'il n'avait pas accès au bon texte et qu'il déteste répondre "je ne sais pas".

C'est exactement le mur que rencontrent la plupart des PME au premier contact avec les agents IA. Un grand modèle de langage, aussi bon soit-il, ne connaît pas vos tarifs, vos contrats, vos procédures internes, votre historique client. Il connaît une moyenne du web figée à sa date d'entraînement. Lui poser une question sur votre métier, c'est demander à un consultant brillant mais qui n'a jamais lu un seul de vos dossiers de répondre quand même. Il le fera. Mal.

Le RAG résout précisément ce problème, et c'est devenu la brique la plus demandée sur nos projets. Le marché le confirme à sa manière : il est évalué autour de 1,94 milliard de dollars en 2025 et projeté vers 9,86 milliards en 2030, soit une croissance annuelle de 38,4 pour cent selon MarketsandMarkets. Derrière le jargon, l'idée est simple, presque banale. Et c'est justement parce qu'elle paraît simple que tant de déploiements ratent : le diable est entièrement dans la mise en oeuvre.

Cet article explique ce qu'est vraiment le RAG sans le vocabulaire qui sert à impressionner, quand le choisir et quand passer à autre chose, ce qu'il coûte réellement (le chiffre va vous surprendre), et les cinq endroits précis où il casse en production. Le tout du point de vue d'un studio qui en met en service pour des PME, pas d'un fournisseur qui vend la techno.

Le RAG en une phrase, puis en une image

En une phrase : le RAG va chercher les passages pertinents dans vos documents au moment où une question est posée, et les fournit au modèle pour qu'il rédige sa réponse à partir de ces passages plutôt qu'à partir de sa mémoire générale.

En une image : imaginez un examen. Le fine-tuning, c'est faire réviser l'étudiant pendant des semaines pour qu'il connaisse la matière par coeur. Le RAG, c'est un examen à livre ouvert : l'étudiant n'a rien mémorisé de spécial, mais on lui autorise les bonnes pages au bon moment, et il compose à partir de ce qu'il a sous les yeux. Pour des connaissances qui changent (un tarif, une procédure, un contrat), l'examen à livre ouvert gagne à tous les coups, parce qu'il suffit de mettre à jour la page, pas de refaire réviser l'étudiant.

Concrètement, un cycle RAG se déroule en deux temps. D'abord, une phase d'ingestion, faite une fois puis mise à jour : on prend vos documents, on les découpe en morceaux (les chunks), on transforme chaque morceau en une représentation numérique (l'embedding, un vecteur), et on range tout ça dans une base vectorielle. Ensuite, à chaque question, la phase de récupération : on transforme la question en vecteur, on cherche les morceaux les plus proches dans la base, on les classe, et on les colle dans le prompt du modèle avec une consigne du type "réponds uniquement à partir de ces extraits, cite tes sources, et si l'information n'y est pas, dis-le".

C'est tout. Et pourtant chacune de ces étapes contient un piège qui, mal géré, transforme un système prometteur en générateur d'erreurs polies.

RAG, fine-tuning, long contexte : trancher en cinq minutes

Trois approches existent pour faire en sorte qu'un modèle "connaisse" votre information. On les confond souvent, et le choix structure tout le projet.

Le fine-tuning réentraîne le modèle sur vos données. Utile pour lui apprendre un comportement : un ton de marque, un format de sortie strict, une compétence répétitive. Inadapté pour des faits, parce que les faits changent et que réentraîner à chaque changement est lent et coûteux. Un modèle fine-tuné sur votre catalogue de mars continuera à citer les prix de mars en juin, sans le savoir.

Le long contexte consiste à coller tous vos documents directement dans la fenêtre de contexte du modèle à chaque question. Séduisant sur le papier maintenant que certaines fenêtres dépassent les 200 000 tokens. Trois problèmes en pratique. Le coût d'abord : vous payez l'intégralité des tokens injectés à chaque appel, ce qui devient ruineux dès que le volume de requêtes monte. La fiabilité ensuite : l'étude de référence sur le phénomène lost in the middle (Liu et al., 2023) a montré que les modèles récupèrent nettement moins bien une information placée au milieu d'un long contexte qu'au début ou à la fin, et les tests de charge publiés par Databricks en 2024 confirment que la performance décroît au-delà d'un seuil (de l'ordre de quelques dizaines de milliers de tokens utiles selon les modèles). La scalabilité enfin : une base documentaire de PME fait vite plusieurs dizaines de milliers de pages, qui ne tiendront jamais dans aucune fenêtre.

Le RAG ne récupère que les quelques passages pertinents et les donne au modèle. Moins cher (on n'envoie que l'utile), plus fiable (peu de bruit dans le contexte), scalable (la base peut faire des millions de chunks), et auditable (on sait quelle source a produit quelle réponse). C'est la fondation par défaut.

La règle de décision qu'on applique en cadrage tient en trois lignes. Vos connaissances changent et vous voulez des réponses sourcées : RAG. Vous voulez surtout imposer un style ou un format constant : fine-tuning, en complément du RAG. Vous avez un seul petit document de référence stable à interroger ponctuellement : le long contexte suffit, inutile de monter une base vectorielle pour dix pages. Dans tout le reste, qui couvre la grande majorité des cas PME, c'est RAG, éventuellement augmenté de long contexte sur l'étape de récupération.

Anatomie d'un pipeline qui tient en production

Voici les étapes réelles, dans l'ordre, avec à chaque fois l'endroit où ça déraille. C'est la partie que les démos sautent et que la production révèle.

1. L'ingestion et le découpage (le levier numéro un)

Avant toute chose, il faut extraire le texte de vos documents : PDF, Word, pages d'un wiki interne, tickets, contrats. Déjà là, un PDF scanné mal océrisé ou un tableau aplati n'importe comment empoisonnent la suite. Puis vient le découpage en chunks, et c'est, de loin, le facteur qui pèse le plus sur la qualité finale.

Découper trop gros, et chaque morceau mélange plusieurs idées : la recherche devient floue et le contexte se dilue. Découper trop fin, et on casse le sens, on sépare une clause de sa condition, une question de sa réponse. Le découpage naïf à taille fixe (tous les 500 mots, par exemple) est la cause la plus fréquente des RAG médiocres qu'on reprend. La bonne pratique 2025, confirmée par les retours d'expérience publiés par les équipes qui font ça à l'échelle, c'est le découpage sémantique : on coupe sur la structure du document (titres, sections, paragraphes) plutôt que sur un compteur de caractères, et on conserve les métadonnées (source, date, section) attachées à chaque chunk. Sur le projet du cabinet RH lillois, le simple passage d'un découpage à taille fixe vers un découpage qui respectait l'arborescence des conventions collectives a fait plus pour la qualité que n'importe quel changement de modèle.

2. L'embedding et le stockage (le poste qui coûte des centimes)

Chaque chunk est transformé en vecteur par un modèle d'embedding, puis stocké. C'est l'étape que les dirigeants imaginent coûteuse, et c'est l'inverse. Avec text-embedding-3-small d'OpenAI à 0,02 USD par million de tokens, vectoriser 10 000 documents de 500 mots revient à environ 0,10 USD, une seule fois. Une base de 100 000 documents coûte quelques dollars par an d'embedding. Pour le stockage, pas besoin d'un service vectoriel américain managé à des volumétries PME : PostgreSQL avec l'extension pgvector, sur une instance européenne à 30 à 80 EUR par mois, tient sans broncher jusqu'à plusieurs millions de chunks. C'est aussi un bon choix pour qui a une exigence de résidence des données, sujet qu'on creuse dans notre tour d'horizon des solutions IA souveraines pour PME.

Sur un projet client PME en 2025, un dirigeant avait budgété plusieurs milliers d'euros pour "la base IA" en pensant à l'infrastructure. La réalité : l'embedding et le stockage coûtaient moins que son abonnement à un outil de visioconférence. L'argent et le temps sont ailleurs, dans le réglage.

3. La récupération hybride (là où la précision se gagne)

Quand une question arrive, on la vectorise et on cherche les chunks les plus proches. La recherche purement vectorielle (sémantique) est excellente pour saisir le sens, mais elle a un angle mort : les correspondances exactes. Une référence produit, un code article, un nom propre, un numéro de contrat passent souvent à travers parce que leur proximité sémantique est faible. La parade, devenue le standard de production en 2025, c'est la recherche hybride : on combine la recherche vectorielle avec une recherche par mots-clés classique (type BM25), on récupère les meilleurs candidats des deux côtés, et on fusionne. Les retours convergent : la recherche hybride bat la recherche vectorielle seule sur la précision factuelle dans la quasi-totalité des cas réels. Pour une PME dont les documents sont truffés de références, de codes et de termes métier exacts, ce n'est pas une option, c'est une nécessité.

4. Le reranking (l'étape qu'on oublie le plus)

Récupérer vingt candidats potentiellement pertinents, c'est bien. Décider lesquels méritent vraiment d'entrer dans le contexte du modèle, c'est mieux. Le reranking passe les candidats dans un second modèle, spécialisé, qui les reclasse finement par pertinence réelle à la question, et on ne garde que le haut du panier. Sans reranking, des passages moyennement pertinents polluent le contexte et tirent le modèle vers des réponses approximatives. C'est l'étape qui fait passer un RAG de "ça marche en démo" à "ça tient en production", et c'est précisément celle qui manque dans la plupart des montages rapides.

5. La génération et le garde-fou anti-hallucination

Enfin, le modèle rédige à partir des passages retenus. Le prompt de génération n'est pas un détail : il doit imposer trois choses. Répondre uniquement à partir des extraits fournis. Citer la source de chaque affirmation. Et, surtout, dire explicitement que l'information n'est pas disponible plutôt que d'inventer quand elle manque. Cette dernière consigne va contre le comportement par défaut des modèles, qui préfèrent une réponse plausible à un aveu d'ignorance. Une couche de vérification supplémentaire, qui contrôle que chaque affirmation citée correspond bien à un passage récupéré, réduit encore les fabrications : des pilotes dans le domaine de la santé publiés en 2025 rapportent des baisses de l'ordre de deux tiers des citations inventées grâce à ce type de contrôle. Pour une PME, la version simple (prompt strict plus obligation de citer) couvre déjà l'essentiel du risque.

Les cinq endroits où ça casse, et ce que ça coûte de les ignorer

On reprend régulièrement des RAG construits trop vite. Les symptômes se ressemblent, les causes aussi.

Le découpage bâclé. Symptôme : le système retrouve des bouts de réponse incomplets ou hors sujet. Cause : découpage à taille fixe qui ignore la structure. C'est le premier endroit qu'on inspecte, et celui qui rapporte le plus une fois corrigé.

La recherche vectorielle seule. Symptôme : l'agent rate les questions contenant une référence exacte, un code, un nom précis, alors qu'il gère bien les questions générales. Cause : absence de recherche hybride. Correctif rapide, gain immédiat sur tout ce qui touche au vocabulaire métier.

L'absence de reranking. Symptôme : les réponses sont dans le bon thème mais imprécises, comme si le modèle avait survolé. Cause : trop de passages moyennement pertinents dans le contexte. Le reranking nettoie.

Le prompt permissif. Symptôme : l'agent invente quand il ne trouve pas, avec aplomb. C'est le cas du cabinet RH du début. Cause : aucune consigne stricte de s'en tenir aux sources et d'avouer l'ignorance.

L'absence d'évaluation. Le piège le plus sournois, parce qu'il est invisible. Sans jeu de questions-réponses de référence pour mesurer la qualité, vous ne savez pas si votre RAG répond juste 95 pour cent du temps ou 70 pour cent. Vous le découvrez quand un client ou un collaborateur tombe sur une erreur. On impose systématiquement un petit corpus d'évaluation (50 à 100 questions réelles avec leurs bonnes réponses) avant la mise en production, et on le rejoue à chaque changement. C'est le même réflexe que pour n'importe quel agent : on en détaille la logique dans notre guide de déploiement d'un agent IA en production.

Une nuance honnête pour équilibrer le tableau : tous les projets n'ont pas besoin des cinq étages d'emblée. Un RAG interne sur une documentation propre et bien structurée, pour un usage à faible enjeu, peut très bien démarrer avec un découpage soigné et un bon prompt, puis ajouter recherche hybride et reranking quand le volume ou l'exigence montent. Sur-ingénierer un petit cas est aussi une erreur. Le bon réflexe : commencer simple, mesurer, et n'ajouter une brique que quand l'évaluation montre qu'elle manque.

Combien ça coûte vraiment

Remettons les ordres de grandeur à l'endroit, parce que l'intuition se trompe presque toujours sur la répartition.

L'embedding : négligeable, on l'a dit, quelques centimes à quelques dollars selon la taille de la base, en one-shot puis à la marge pour les mises à jour.

Le stockage vectoriel : 30 à 80 EUR par mois sur une instance PostgreSQL pgvector européenne, suffisant pour la grande majorité des PME. Inutile de payer un service vectoriel premium tant qu'on n'a pas franchi des volumétries que la plupart n'atteindront jamais.

La génération : c'est le poste récurrent principal, et il dépend du volume de requêtes et du modèle choisi. Pour une PME qui traite quelques milliers de requêtes par mois, comptez typiquement 40 à 300 EUR par mois d'API de génération. Une bonne pratique pour le contenir : utiliser un petit modèle pour les étapes simples (reformulation de la question, classification) et réserver le gros modèle à la rédaction finale. On détaille tous ces postes dans notre guide des coûts réels d'un agent IA en production.

Le build : c'est ici que se trouve l'essentiel de l'investissement initial. Préparer les documents, régler le découpage, brancher la recherche hybride et le reranking, écrire le prompt de génération, monter le corpus d'évaluation, intégrer le tout à vos outils. C'est du temps d'ingénierie, et c'est précisément ce temps qui sépare un RAG qui inspire confiance d'un RAG qui érode la confiance à chaque réponse approximative. Autrement dit : l'infrastructure d'un RAG est bon marché, la qualité d'un RAG se paie en méthode.

Architecture type qu'on déploie pour une PME

Pour fixer les idées, voici la stack qu'on met en place par défaut, ajustable selon les contraintes.

Ingestion avec un découpage sémantique respectant la structure des documents, et conservation des métadonnées (source, date, section) pour pouvoir citer et filtrer. Embedding via un modèle économique (text-embedding-3-small ou un équivalent européen quand la souveraineté l'exige). Stockage sur PostgreSQL avec pgvector chez un hébergeur européen, ce qui garde les données dans le périmètre. Récupération hybride (vectoriel plus mots-clés) suivie d'un reranking pour ne retenir que les meilleurs passages. Génération avec un prompt strict (réponse sourcée, aveu d'ignorance obligatoire) sur un modèle dimensionné au cas d'usage. Et, en amont comme en aval, une couche d'évaluation rejouée à chaque modification.

Le branchement aux outils de l'entreprise (le CRM, l'outil de tickets, la base documentaire) passe de plus en plus par le standard MCP, qui normalise la façon dont un agent accède à des sources externes. Le RAG et MCP sont complémentaires : MCP gère la connexion technique aux sources, le RAG gère la pertinence de ce qu'on en extrait. On explique ce protocole et son intérêt pour les PME dans notre article dédié au Model Context Protocol.

Un point de vigilance souvent négligé : la résidence des données ne se joue pas qu'au niveau du modèle. Si votre RAG est impeccablement européen mais que l'agent pousse ses réponses dans un SaaS américain sans accord de traitement correct, l'exercice de souveraineté est ruiné au dernier maillon. Le périmètre se vérifie de bout en bout, source par source.

Ce qu'on retient

Le RAG est la brique qui transforme un agent IA générique, qui parle bien mais ne connaît pas votre métier, en agent qui répond à partir de vos documents, à jour et sourcés. Pour une PME, c'est presque toujours le bon point de départ, devant le fine-tuning (qui sert le style, pas les faits) et devant le pari du tout long contexte (plus cher, moins fiable au-delà d'un certain volume, et borné par la taille de la fenêtre).

L'intuition à corriger en priorité : le coût n'est pas dans l'infrastructure. Vectoriser une base entière coûte quelques dollars, la stocker quelques dizaines d'euros par mois. Le vrai investissement, c'est la méthode qui garantit que le système retrouve la bonne information : un découpage qui respecte le sens, une recherche hybride, un reranking, un prompt qui interdit d'inventer, et un corpus d'évaluation pour mesurer plutôt que d'espérer. Quand un RAG hallucine, le coupable est presque toujours la récupération, pas le modèle.

Si vous êtes CTO ou dirigeant d'une PME de 10 à 100 personnes et que vos équipes passent un temps déraisonnable à chercher la bonne information dans des documents épars (les études de McKinsey et IDC chiffrent ce temps perdu autour de 15 à 20 pour cent d'une journée de travail), un RAG bien construit est probablement l'un des projets IA au meilleur rapport valeur sur effort que vous puissiez lancer cette année. Le piège n'est pas la technologie, qui est mature et bon marché. Le piège est de le construire vite et mal, puis de conclure que "l'IA hallucine trop pour notre métier", alors que c'est la mise en oeuvre qui était en cause. Cadrez le découpage, la récupération et l'évaluation dès le départ, et le reste suit.